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

Re: [802.3EEESG] Modified Objectives



Ok, thanks for the correction.  My concern still stands.  While the objectives as written don't preclude a link speed change, they can be satisfied with only tweaks to the pjy signalling.  Now, this may not be what anyones proposing now, but don't you think the objectives should say something about changing the link speed (or other parameter?) if that is where the lion's share of the power savings is expected to come from?
All of the data backing up eee for the

-----Original Message-----
From: "Mike Bennett" <mjbennett@LBL.GOV>
To: "STDS-802-3-EEE@listserv.ieee.org" <STDS-802-3-EEE@listserv.ieee.org>
Sent: 5/29/07 10:59 PM
Subject: Re: [802.3EEESG] Modified Objectives

George,

The actual modified objective are:

Define a mechanism to reduce power consumption during
periods of low link utilization for the following PHYs
– 100BASE-TX (Full Duplex)
– 1000BASE-T (Full Duplex)
– 10GBASE-T
– 10GBASE-KR
– 10GBASE-KX4
• Define a protocol to coordinate transitions to or from a lower
level of power consumption
• The transition time to and from the lower level of power
consumption should be transparent to upper layer protocols and
applications, no more than TBD
• The link status should not change as a result of the transition
• No frames in transit shall be dropped or corrupted during the
transition to and from the lower level of power consumption

There was concern over the use of the word "state" as it could mean a 
state-machine would be required. The objectives as amended are shown above.


George Zimmerman wrote:
>
> I understand that the objectives were modified to read:
>
> • Define a mechanism to reduce power consumption during
>
> periods of low link utilization for the following PHYs
>
> – 100BASE-TX
>
> – 1000BASE-T
>
> – 10GBASE-T
>
> – 1000BASE-KX
>
> – 10GBASE-KR
>
> – 10GBASE-KX4
>
> • Define a protocol to coordinate transitions to or from a lower
>
> power consumption state
>
> • The transition time to and from the lower power state should be
>
> transparent to upper layer protocols and applications
>
> • The link status should not change as a result of the transition
>
> • No frames in transit shall be dropped or corrupted during the
>
> transition to and from the lower power state
>
> As I read the modified objectives, I see that the objectives would be 
> achieved if we just defined a set of lower power PHYs, without any 
> mechanism to change link speed. The data presented in the CFI and in 
> contributions (particularly for 100BASE-T and gigabit) suggests that 
> most of the power savings would come from other than the PHY, and 
> would be triggered elsewhere in the system by a change in link speed.
>
> Is this the intent that was considered in the group?
>
Yes - see barrass_1_0507.pdf. I believe this is all covered in the 
adopted PAR document.
>
> The scope of the system over which “lower power state” is considered 
> is not defined. (from the implication of the first statement, this was 
> about power consumption for the PHY). If you assume that it is only 
> about the PHY, then we will not achieve significant power savings, and 
> I would say that the 5 critters will be difficult to satisfy at best. 
> (certainly there has been little or no work showing that other than 
> changing link speed there would be savings in power and hence either 
> economic or technical feasibility)
>
> I would suggest that at least the first objective be modified to 
> include the mac and controller as follows:
>
> Define a mechanism to reduce power consumption of the overall Ethernet 
> system (e.g., MAC/PHY) during periods of low link utilization with the 
> following PHY types:
>
> ….
>
> It would be better to say for example Controller/PHY, Switch/PHY – but 
> 802.3 doesn’t define these entities – if someone knows better, please 
> help out.
>
> Sorry to be wording these things from a remote location… Please take 
> it as an attempt at constructive work.
>
I appreciate you working on this as best you can from remote. I believe 
this will come up in the group today.

Regards,

Mike
>
> -george
>