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

Re: [802.3EEESG] On the topic of tranistion time (was Re: [802.3EEESG] Comments on our work from Vern Paxson)



Thanks for the clarification.

Geoff Thompson wrote:
> Ken-
> 
> I believe you misunderstood my suggestion and thesis.
> 
> My points were:
>         1) There is a new class of consumer equipment and protocols 
> being developed in 802.1AVB. This "stuff" will have much more stringent 
> requirements for both latency and jitter, both in terms of absolute and 
> variability. I believe the requirements will be such that the 
> applications will not tolerate speed shifts during their streaming 
> operations.
> 
>         2) The market volume and duty cycle of these systems will be 
> such it will absolutely NOT OK to disable (or ignore) power saving modes.
> 
>         3) These systems are not "legacy", they are current standards 
> projects. As such, hooks can be put into the protocols to support power 
> saving modes. That is, when a streaming application is firing up, the 
> device could send a packet requesting that the network switch to the 
> higher speed that is necessary to support the streaming application that 
> is firing up.
> 
> I was, by no means, suggesting "a soft state of "link power management = 
> off"
> 
> I was suggesting that link power management could be explicitly 
> commanded to change speeds by active packets in addition to a passive 
> traffic monitoring of (legacy) traffic levels.
> 
> I hope this clears up any misunderstanding.
> 
> Regards,
> 
> Geoff Thompson
> \
> At 08:21 AM 6/19/2007 , Ken Christensen wrote:
>> Hello all, if I may weigh-in...  It is no doubt that there will be 
>> applications for which EEE is not suitable (and should be disabled). 
>> Such applications may include latency-sensitive cluster computing and 
>> some realtime streaming applications.  But, will these be a majority 
>> of applications?  So, maybe Vern's comments may still hold for the 
>> majority of cases.  Over time it seems that applications have become 
>> more robust, not less so, to loss and delay. As bandwidth, processing, 
>> and memory capacity have all increased the need for fine grained 
>> control (for classic "QoS") has diminished.
>>
>> In a previous email to this list, Geoff suggested a control packet to 
>> maintain a soft state of "link power management = off".  Did I 
>> understand this correctly?  I think that remote management of power 
>> state of links and devices will become an interesting problem area for 
>> many protocol standards.  DMTF looked at this in 2004.  Should such 
>> power management control occur at the 802.3 level?
>>
>> For speed of packet transmission, there are two factors: transmission 
>> time and end-to-end latency.  For small packets, the latter may 
>> dominate.  For a 64 byte packet, the transmission time at 100 Mb/s is 
>> about 5 microseconds and at 1 Gb/s it is about 0.5 microseconds... is 
>> there any protocol (or operating system or device) that is 
>> sufficiently sensitive to tell the difference between 0.5 and 5 
>> microseconds?
>>
>> Thanks for letting me say a few words.
>>
>> Regards,
>>
>> Ken Christensen
>> Department of Computer Science and Engineering
>> University of South Florida
>> Phone: (813) 974-4761
>> Web: http://www.csee.usf.edu/~christen

-- 
Ken Christensen
Department of Computer Science and Engineering
University of South Florida
Phone: (813) 974-4761
Web: http://www.csee.usf.edu/~christen