Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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

Hi Brad,

I will add my $.02 on your comments;


> 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


Dan Dove