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