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

Re: [802.3EEESG] The paradox of lower speed operation



Title: RE: [802.3EEESG] The paradox of lower speed operation

I suppose you could send smaller frames at the lower speed, maybe your signaling frame. J

Though this still affects the buffer size required. By the way, I thought about the buffer requirements after the meeting. Even if we go to 0 speed, I think there is a small boundary condition that requires the buffer size to accommodate the time to change to the 0 speed plus the time to change to the higher speed. This happens if frames arrives for transmission after the decision to switch to the 0 speed.

--Jim M.

-----Original Message-----
From: Hugh Barrass [mailto:hbarrass@CISCO.COM]
Sent: Tuesday, November 20, 2007 12:13 PM
To: STDS-802-3-EEE@LISTSERV.IEEE.ORG
Subject: [802.3EEESG] The paradox of lower speed operation

All,

For those of you that missed the discussions in Atlanta (and some of you

who didn't :-) an interesting paradox emerged for PHY proposals that

offer very fast transition from a reduced speed mode back to the full speed.

If the transition time is less than the time to transmit a maximum

length frame at the lower speed, then it's better not to send data at

the lower speed.

This is because a PHY that is running at a lower speed must allow a

frame in progress to complete before changing to the higher speed

whereas a PHY that does not keep the lower speed channel active may

transition immediately. This effect clearly becomes more pronounced if

we consider compatibility with jumbo or super-jumbo frames.

In the examples that were presented to the TF we saw two almost

identical proposals for PHYs that could resume 10Gbps operation in

~10uS. One of them defined a gigabit "subset mode" the other defined a

deep sleep idle mode. It is interesting that the transition buffering

requirement of the PHY that keeps the gigabit channel alive is greater

than that of the PHY that goes into deep sleep as a max length frame

requires 16uS to complete at 1Gbps. Similarly, it is better to use a

resume time of less than 100uS than to drop back to 100Mbps.

I think that this analysis, along with the very fast transition

proposals, changes the nature of the task force away from the "PHY speed

changes" that we had been concentrating on up till now.

Hugh.