|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
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.
Level One Communications, Austin Design Center
(512) 407-2135 office
(512) 589-4438 cellular
From: Dan Dove [SMTP:dan_dove@xxxxxx]
Sent: Tuesday, August 03, 1999 12:30 PM
Subject: Re: More on this 10/9.58464 data rate...
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?
> Brad Booth