RE: Proposal for accomodating 10.0000 and 9.58464 line rates
Deference logic has to be implemented anyway. The question is whether to
use only TXEN (as is required
for full duplex) or CRS too.
At 03:05 PM 7/23/99 -0700, you wrote:
>I knew there had been a non-frame-based proposal for 802.3x so I should have
>realized that there was probably previous work done that could be
>referenced. There was also a proposal along these lines in the early days
>of 802.3z to support flow control for full duplex repeaters. In both cases
>it was conceptually different from today's issue because these proposals
>were for the PHY to generate a flow control signal based on some information
>obtained from the far end of the link, whereas today we are asking the PHY
>to generate the signal based on local conditions. The impact on the MAC is
>the same, however, regardless of how the PHY generates the signal.
>Regarding having to implement half-duplex functions in a 10G MAC, I guess
>this proposal does require some of this. I would have thought that the bulk
>of the half-duplex complexity was in collision handling, backoff, and
>retransmission. How painful is deference by itself?
>> From: Shimon Muller[SMTP:Shimon.Muller@xxxxxxxxxxx]
>> Reply To: Shimon Muller
>> Sent: Friday, July 23, 1999 2:23 PM
>> To: stds-802-3-hssg@xxxxxxxx
>> Subject: Re: Proposal for accomodating 10.0000 and 9.58464 line rates
>> This proposal is very similar to the proposal that some of us presented to
>> 802.3x a few years ago. At that time the Task Force decided to go with a
>> frame based approach, but the the basic mechanism that we had would work
>> I still have the changes that were needed to accommodate the interfaces
>> the PASCAL code, so we can leverage from that.
>> The main problem that I have with it though, is that the 10-GE MAC will
>> have to implement quite a bit of the half-duplex functionality. I kinda
>> that we can get rid of it once and for all....