RE: More on this 10/9.58464 data rate...

["Booth, Brad" <bbooth@xxxxxxxxxx>]

Title: RE: More on this 10/9.58464 data rate...

Dan,

Nice to see you back from your vacation! J

From point #2, I would agree with you if the signal is a HOLD, rather than the CRS (as you explained in another email to the reflector).

From point #3, I thought about that, and there is a way around that which is very similar in concept to the HOLD signal, but without needing a signal from the PHY.

Point #2 and #3 are in essence very similar.  Point #2 is structured to have the PHY request a longer IPG based on the current packet it is receiving for transmission on the line.  Point #3 is structured to have the MAC lengthen the IPG based on the current packet it is transmitting to the PHY.

Thanks,
Brad

Brad Booth
bbooth@xxxxxxxxxx
Level One Communications, Austin Design Center
(512) 407-2135 office
(512) 589-4438 cellular

-----Original Message-----
From:   Dan Dove [SMTP:dan_dove@xxxxxx]
Sent:   Tuesday, August 03, 1999 12:30 PM
To:     stds-802-3-hssg@xxxxxxxx
Subject:        Re: More on this 10/9.58464 data rate...




Hi Brad,

I will add my $.02 on your comments;

Dan

> bbooth@xxxxxxxxxx wrote:
>
> Looking at this issue, there seems to be a need for 3 things:
> 1) to provide a MAC data rate of 10 Gb/s to make this an easier sell
> into the existing Ethernet marketplace and to simplify uplinks for
> existing Ethernet products
> 2) to provide a low cost LAN solution (part of the PAR and 5 criteria)
> 3) to provide a WAN solution using the OC-192 installed base
>
> The problem, as everyone is probably well aware of, is the difference in
> data rates between 10 Gb/s MAC/PHY combinations for the LAN, and the
> OC-192 data rate of 9.58464 Gb/s.  To resolve this data rate matching
> issue, I believe their are 3 possible solutions:
> 1) Use a local 802.3x flow control between the WAN PHY and the MAC.  The
> advantage is that there is an existing standard to perform this
> operation.  The disadvantage is that there would need to be a mechanism
> to distinguish between local and remote flow control messages.

I agree. I think this is very complicated and would be problematic in the
case where the receiver is getting data at line rate. Injecting a PAUSE
frame into the stream seems impossible without impacting data.

> 2) Use deference with the indication of CRS/HOLD signal.  The advantage
> is that it would operate as a local flow control.  The disadvantage is
> that there would be an impact on the standard to add this capability and
> there may be an issue with backwards compatibility, especially if a 1/10
> Gb/s MAC is designed.

I disagree with the compatibility issue. For 1Gbs MAC, no-connect the
signal. I agree that it adds an impact to the standard, but then, 10G
will require a lot of work... what's a little more?




> 3) Use of PHY management registers and management layer.  This solution
> would require the management layer to read the PHY management registers
> (probably register 15) prior to data transmission to determine what the
> data rate is for the PHY.  The management layer would indicate the PHY's
> data rate to the MAC, which would then alter its IPG to compensate.  The
> advantage is that this is a relative simple change to the MAC.  The
> disadvantage is that this depends on a management layer.




The big dis-advantage to this approach that seems to be left out, is that
if we pre-negotiate a larger IPG, we have destined small-packet throughput
to be substantially lower than it needs to be. With option #2, the PHY could
accept multiple 64 byte packets with standard IPGs, then when close to
overflowing, assert the HOLD signal and extend the IPG for one packet.

> Those are my thoughts.  Comments, thoughts?  Any other solution that
> could be implemented?
>
> Thanks,
> Brad
>
> Brad Booth
> bbooth@xxxxxxxxxx
>

Regards,

Dan Dove