Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Ethernet Goes Green: Page 4 of 5

The EEE work will have to go through a number of standards review steps to address implementation issues and gain consensus from all the EEE-participating vendors. We're unlikely to see final approval before the end of 2009--and even then, you'll need EEE-capable equipment on both ends of an Ethernet link to benefit.

Meantime, a number of technical challenges must be worked out. The biggest is how to increase or decrease Ethernet speed quickly enough to avoid packet loss and the resultant problems with apps and the end-user experience. Developers from companies participating in the EEE are working to address this. Current tests have shown that the time it takes to make the required change in Ethernet speed can vary significantly, from a few microseconds to 1 to 20 milliseconds. Once you get into the latter range, there's potential for noticeable packet drops, enough to cause TCP to slow down retransmissions. One possible solution is to use some type of flow control during the speed change, but this could create its own problems if switch buffers fill up and have to drop packets anyway. And imagine trying to do this through a VoIP phone that's being used as a switch for a locally attached PC.

Exchanging Frames

You may be thinking that the EEE's methods sound a lot like autonegotiation. But autonegotiation is too slow to make RPS practical, though early research with RPS (known in 2004 as ALR, or Adaptive Link Rate) by Bruce Nordman of Lawrence Berkeley National Labs and South Florida's Christensen used autonegotiation to change speeds, to test the general concept.

RPS must use a faster mechanism than autonegotiation, something that probably will involve a simple frame exchange. Given the problems with autonegotiation, we hope initial versions of RPS work more smoothly. That won't be a problem, according to Howard Frazier, Broadcom's technical director for technical strategy, who is heavily involved with the EEE initiative and chaired the 802.3 group that standardized autonegotiation. He stressed that lessons learned from autonegotiation will be applied to RPS, and that implementing RPS is less risky than implementing autonegotiation because RPS can be turned off.