Subject: [eman] Power states - time to dump ACPI and DMTF

From: Bruce Nordman <[email-masked]>
Date: Thu, 10 Mar 2011 22:37:04 -0800

(all below as contributor)

For many decades, electrical products were usually just on or off - a
2-state power model.  In the last several decades, we have added many
electronic products with a 3-state model - on, sleep, and off.  This is
necessary and existing complexity.  Our discussions around power states boil
down to what complexity do we want to add to the 3-state model, and why the
burden is justified.

In discussions on this email list, in I-drafts, and in person, the existing
listings of power states from ACPI and DMTF are often referenced as good
candidates for eman to adopt in some way.  ACPI is a hugely important
technology, and it enables large amounts of user functionality and energy
savings.  I am less familiar with the reach of DMTF in practice, but its
depth and breadth of membership are compelling.  While I agree they both
deserve close examination, I think we can safely drop them from our
discussions of what to define as their complexity is more a distraction than
an asset.

The basic ACPI list is of  “Global System States” which “apply to the entire
system”.  There are four of these (G0-G3); G0 is on (“working”) and G1 is
sleep (“sleeping”).  G2 and G3 both forms of off (only distinguished by
whether a device is completely depowered and whether it is safe to
disassemble or not, and these distinctions seems quite minor for eman
purposes).  Thus, the ACPI Global states are essentially on/sleep/off, the
3-state power model.

            ACPI lists five “Sx” sleep states (S0 is on).  S5 is actually
the G2 Off state (so not a sleep state at all), and current implementations
do not use S1 or S2, so in practice there are only two ACPI sleep states: S3
and S4.  S3 is the ordinary system sleep, with quick wakeup.  S4 is the
hibernate state (with system memory saved in non-volatile memory, possibly a
hard disk) which typically has long times to return to operation (often tens
of seconds).   The 1-2 second wake time from S3 for modern personal
computers is compatible with many IP protocol usages, e.g. initiating a TCP
connection.  The tens of seconds time for S4 on current systems is not.  So,
the only potential addition that the Sx states add to on/sleep/off is
hibernate (and reasonable people can differ on whether it is a fourth basic
state, a form of sleep, or a form of off).

            ACPI does define processor states (Cx) and device states (Dx)
(collectively Px), but these are the states of particular components, not of
the system as a whole.  It may be useful to expose these through some
mechanism, but they are distinct from the power state.

            DMTF essentially took the ACPI Gx states plus hibernate and
added states that are commands and/or transitions.  (Is "Master Bus Reset" a
power state?  I think not).  If we don’t include commands or transitions (I
think we should not), then these reduce to the ACPI states.

            My conclusion: *ACPI and DMTF do not significantly change the
3-state power model.*  If* *we want to talk about states beyond the 3-state
model, it is more clear to simply reference those extensions directly (e.g.
how best to treat hibernate).  Note that this discussion - and all others on
the list - are grounded in electronic devices.  Other devices generally have
a 2-state model (e.g. a light), or 3 states, but on, off, and "ready" (think
a microwave oven).

--Bruce

-- 
*Bruce Nordman*
Lawrence Berkeley National Laboratory
eetd.lbl.gov/ea/nordman
[email-masked]
510-486-7089
m: 510-501-7943

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 11 Mar 2011 10:37:24 +0100

Hi Bruce,

I understand your preference for a simple off-sleep-on model for power states.
How would we model a device with a battery then 
  - it is off, but the empty battery is being charged
  - it is on, but fully supplied with power from the battery.

On way would be treating the (internal) battery as separate device.
In this case: Can we map charging/discharging/full/empty to off-sleep-on?

Thanks,

    Juergen

Am 11.03.2011 um 07:37 schrieb Bruce Nordman:

> For many decades, electrical products were usually just on or off - a 2-state power model.  In the last several decades, we have added many electronic products with a 3-state model - on, sleep, and off.  This is necessary and existing complexity.  Our discussions around power states boil down to what complexity do we want to add to the 3-state model, and why the burden is justified.
> 
> In discussions on this email list, in I-drafts, and in person, the existing listings of power states from ACPI and DMTF are often referenced as good candidates for eman to adopt in some way.  ACPI is a hugely important technology, and it enables large amounts of user functionality and energy savings.  I am less familiar with the reach of DMTF in practice, but its depth and breadth of membership are compelling.  While I agree they both deserve close examination, I think we can safely drop them from our discussions of what to define as their complexity is more a distraction than an asset.
> 
> The basic ACPI list is of  “Global System States” which “apply to the entire system”.  There are four of these (G0-G3); G0 is on (“working”) and G1 is sleep (“sleeping”).  G2 and G3 both forms of off (only distinguished by whether a device is completely depowered and whether it is safe to disassemble or not, and these distinctions seems quite minor for eman purposes).  Thus, the ACPI Global states are essentially on/sleep/off, the 3-state power model.
>             ACPI lists five “Sx” sleep states (S0 is on).  S5 is actually the G2 Off state (so not a sleep state at all), and current implementations do not use S1 or S2, so in practice there are only two ACPI sleep states: S3 and S4.  S3 is the ordinary system sleep, with quick wakeup.  S4 is the hibernate state (with system memory saved in non-volatile memory, possibly a hard disk) which typically has long times to return to operation (often tens of seconds).   The 1-2 second wake time from S3 for modern personal computers is compatible with many IP protocol usages, e.g. initiating a TCP connection.  The tens of seconds time for S4 on current systems is not.  So, the only potential addition that the Sx states add to on/sleep/off is hibernate (and reasonable people can differ on whether it is a fourth basic state, a form of sleep, or a form of off).
>             ACPI does define processor states (Cx) and device states (Dx) (collectively Px), but these are the states of particular components, not of the system as a whole.  It may be useful to expose these through some mechanism, but they are distinct from the power state.
> 
>             DMTF essentially took the ACPI Gx states plus hibernate and added states that are commands and/or transitions.  (Is "Master Bus Reset" a power state?  I think not).  If we don’t include commands or transitions (I think we should not), then these reduce to the ACPI states.
> 
>             My conclusion: ACPI and DMTF do not significantly change the 3-state power model.  If we want to talk about states beyond the 3-state model, it is more clear to simply reference those extensions directly (e.g. how best to treat hibernate).  Note that this discussion - and all others on the list - are grounded in electronic devices.  Other devices generally have a 2-state model (e.g. a light), or 3 states, but on, off, and "ready" (think a microwave oven).
> 
> --Bruce
> 
> 
> -- 
> Bruce Nordman
> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman

---

From: Rolf Winter <[email-masked]>
Date: Fri, 11 Mar 2011 13:36:25 +0000

Hi,

just thinking out loud here.

The thing which seems to complicate matters here significantly is batteries. You either A) try to consider battery state in the devices' power state or you B) leave it separate in its own MIB module (as described e.g. here http://tools.ietf.org/html/draft-quittek-eman-battery-mib-00 where we have battery states full(1), partiallyCharged(2), empty(3), charging(4), discharging(5), unknown(6)). I think these are the trade-offs:

Option A) You can always tell from the device power state whether it is drawing power or not ("off but charging" e.g.) and you might be able to order them in a way that a higher state always translates to higher power draw. It however seems to complicate power states.

Option B) If a battery is present, you cannot tell from the device's power state whether is it drawing power or not ("off" could be really "off but charging"). The device power states can be modelled cleaner though and you'd need to look closer to see what the battery state is to be sure there is no power draw.

Is that the trade-off we're talking about or is there anything else that needs to be considered?

Best,

Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Juergen Quittek
> Sent: Freitag, 11. März 2011 10:37
> To: Bruce Nordman
> Cc: eman mailing list
> Subject: Re: [eman] Power states - time to dump ACPI and DMTF
> 
> Hi Bruce,
> 
> 	For many decades, electrical products were usually just on or off
> - a 2-state power model.  In the last several decades, we have added
> many electronic products with a 3-state model - on, sleep, and off.
> This is necessary and existing complexity.  Our discussions around
> power states boil down to what complexity do we want to add to the 3-
> state model, and why the burden is justified.
> 
> 
> 
> 
> 
> 	In discussions on this email list, in I-drafts, and in person,
> the existing listings of power states from ACPI and DMTF are often
> referenced as good candidates for eman to adopt in some way.  ACPI is a
> hugely important technology, and it enables large amounts of user
> functionality and energy savings.  I am less familiar with the reach of
> DMTF in practice, but its depth and breadth of membership are
> compelling.  While I agree they both deserve close examination, I think
> we can safely drop them from our discussions of what to define as their
> complexity is more a distraction than an asset.
> 
> 
> 
> 
> 	The basic ACPI list is of  "Global System States" which "apply to
> the entire system".  There are four of these (G0-G3); G0 is on
> ("working") and G1 is sleep ("sleeping").  G2 and G3 both forms of off
> (only distinguished by whether a device is completely depowered and
> whether it is safe to disassemble or not, and these distinctions seems
> quite minor for eman purposes).  Thus, the ACPI Global states are
> essentially on/sleep/off, the 3-state power model.
> 
> 	            ACPI lists five "Sx" sleep states (S0 is on).  S5 is
> actually the G2 Off state (so not a sleep state at all), and current
> implementations do not use S1 or S2, so in practice there are only two
> ACPI sleep states: S3 and S4.  S3 is the ordinary system sleep, with
> quick wakeup.  S4 is the hibernate state (with system memory saved in
> non-volatile memory, possibly a hard disk) which typically has long
> times to return to operation (often tens of seconds).   The 1-2 second
> wake time from S3 for modern personal computers is compatible with many
> IP protocol usages, e.g. initiating a TCP connection.  The tens of
> seconds time for S4 on current systems is not.  So, the only potential
> addition that the Sx states add to on/sleep/off is hibernate (and
> reasonable people can differ on whether it is a fourth basic state, a
> form of sleep, or a form of off).
> 
> 
> 	            ACPI does define processor states (Cx) and device
> states (Dx) (collectively Px), but these are the states of particular
> components, not of the system as a whole.  It may be useful to expose
> these through some mechanism, but they are distinct from the power
> state.
> 
> 
> 
> 
> 	            DMTF essentially took the ACPI Gx states plus
> hibernate and added states that are commands and/or transitions.  (Is
> "Master Bus Reset" a power state?  I think not).  If we don't include
> commands or transitions (I think we should not), then these reduce to
> the ACPI states.
> 
> 
> 
> 
> 	            My conclusion: ACPI and DMTF do not significantly
> change the 3-state power model.  If we want to talk about states beyond
> the 3-state model, it is more clear to simply reference those
> extensions directly (e.g. how best to treat hibernate).  Note that this
> discussion - and all others on the list - are grounded in electronic
> devices.  Other devices generally have a 2-state model (e.g. a light),
> or 3 states, but on, off, and "ready" (think a microwave oven).
> 
> 
> 
> 
> 	--Bruce
> 
> 
> 
> 
> 	--
> 	Bruce Nordman

---

From: Ted Ghose <[email-masked]>
Date: Fri, 11 Mar 2011 08:00:36 -0800

Hi Rolf, Juergen

I like Rolf's idea very much. We should extend number of states
to accommodate other sub states.

Here is one question I do have for Juergon, as handling the battery keeps
coming up in all the discussions.

If the device is off, but battery is charging, who is reporting that and
how? Is battery itself has the intelligence to do so? In that case, can we
treat it as a separate device independent of the device it is connected to,
and then we could simplify the model.

In the other case, though, if device is turned off, there is no one to tell
what the battery is doing, unless an intelligent PDU or someone is aware of
that device. Which comes to some source - sink model as well.

Could you please clarify your thoughts?

thanks

-tg-
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,.
                     Save time... see it my way
*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_,.-:*'``'*:-.,_:-.,_,.-:**:-.,_,.

On Fri, Mar 11, 2011 at 5:36 AM, Rolf Winter <[email-masked]> wrote:

> The thing which seems to complicate matters here significantly is
> batteries. You either A) try to consider battery state in the devices' power
> state or you B) leave it separate in its own MIB module (as described e.g.
> here http://tools.ietf.org/html/draft-quittek-eman-battery-mib-00 where we
> have battery states full(1), partiallyCharged(2), empty(3), charging(4),
> discharging(5), unknown(6)). I think these are the trade-offs:
>
> Option A) You can always tell from the device power state whether it is
> drawing power or not ("off but charging" e.g.) and you might be able to
> order them in a way that a higher state always translates to higher power
> draw. It however seems to complicate power states.
>
> Option B) If a battery is present, you cannot tell from the device's power
> state whether is it drawing power or not ("off" could be really "off but
> charging"). The device power states can be modelled cleaner though and you'd
> need to look closer to see what the battery state is to be sure there is no
> power draw.
>

---

From: "Chris Verges" <[email-masked]>
Date: Fri, 11 Mar 2011 08:04:18 -0800

Hi Ted,

I might be putting words into Rolf's mouth, but here are my thoughts on this:

Certain devices, like servers, that contain a Lights Out Management (LOM) card will be able to report the server's power supply as "off" but the battery as "charging".  This combination for the server entity results in the desired effect.

Rolf, anywhere in the ballpark?

Chris

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Ghose
Sent: Friday, March 11, 2011 8:01 AM
To: Rolf Winter
Cc: Bruce Nordman; eman mailing list
Subject: Re: [eman] Power states - time to dump ACPI and DMTF

Hi Rolf, Juergen

I like Rolf's idea very much. We should extend number of states to accommodate other sub states. 

Here is one question I do have for Juergon, as handling the battery keeps coming up in all the discussions. 

If the device is off, but battery is charging, who is reporting that and how? Is battery itself has the intelligence to do so? In that case, can we treat it as a separate device independent of the device it is connected to, and then we could simplify the model.

In the other case, though, if device is turned off, there is no one to tell what the battery is doing, unless an intelligent PDU or someone is aware of that device. Which comes to some source - sink model as well.

thanks

-tg-

Hi,

Best,

Rolf

---

From: "John Parello (jparello)" <[email-masked]>
Date: Fri, 11 Mar 2011 09:34:57 -0800

HI Bruce,

I would also add to that how would you model a simple motor with gears.
If you want to monitor the power over time (energy)  you would not be
able to trend  or compare the usage of the motor as it did useful work.

With EEE and the changes in networking gear the power characteristic
will vary as the device does useful work exactly as motors do.

An analogy would be a car with gears. The power characteristics of a car
is very different depending upon what gear you are in. Your proposal
would be to ignore the power capabilities and just model it as on? So as
you see a trend of usage increase did the motor become in disrepair or
did you change gears.

Also I'd like to draw from experience here.  We had on and off for
decades on our product lines. Once we introduced the notion of a
spectrum of states our product teams (over 20 that are comparable to
small companies) and 40 partners all embraced it and were able to model
and provide lower operational states by choosing to implement states
from that spectrum of possibilities.

On and off and standby  is just saying there is only black and white and
other and does provide not color into the spectrum of states.

Jp

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Juergen Quittek
Sent: Friday, March 11, 2011 1:37 AM
To: Bruce Nordman
Cc: eman mailing list
Subject: Re: [eman] Power states - time to dump ACPI and DMTF

Hi Bruce,

I understand your preference for a simple off-sleep-on model for power
states.

In this case: Can we map charging/discharging/full/empty to
off-sleep-on?

Thanks,

    Juergen

For many decades, electrical products were usually just on or off - a
2-state power model.  In the last several decades, we have added many
electronic products with a 3-state model - on, sleep, and off.  This is
necessary and existing complexity.  Our discussions around power states
boil down to what complexity do we want to add to the 3-state model, and
why the burden is justified.

In discussions on this email list, in I-drafts, and in person, the
existing listings of power states from ACPI and DMTF are often
referenced as good candidates for eman to adopt in some way.  ACPI is a
hugely important technology, and it enables large amounts of user
functionality and energy savings.  I am less familiar with the reach of
DMTF in practice, but its depth and breadth of membership are
compelling.  While I agree they both deserve close examination, I think
we can safely drop them from our discussions of what to define as their
complexity is more a distraction than an asset.

The basic ACPI list is of  "Global System States" which "apply to the
entire system".  There are four of these (G0-G3); G0 is on ("working")
and G1 is sleep ("sleeping").  G2 and G3 both forms of off (only
distinguished by whether a device is completely depowered and whether it
is safe to disassemble or not, and these distinctions seems quite minor
for eman purposes).  Thus, the ACPI Global states are essentially
on/sleep/off, the 3-state power model.

            ACPI does define processor states (Cx) and device states
(Dx) (collectively Px), but these are the states of particular
components, not of the system as a whole.  It may be useful to expose
these through some mechanism, but they are distinct from the power
state.

            DMTF essentially took the ACPI Gx states plus hibernate and
added states that are commands and/or transitions.  (Is "Master Bus
Reset" a power state?  I think not).  If we don't include commands or
transitions (I think we should not), then these reduce to the ACPI
states.

            My conclusion: ACPI and DMTF do not significantly change the
3-state power model.  If we want to talk about states beyond the 3-state
model, it is more clear to simply reference those extensions directly
(e.g. how best to treat hibernate).  Note that this discussion - and all
others on the list - are grounded in electronic devices.  Other devices
generally have a 2-state model (e.g. a light), or 3 states, but on, off,
and "ready" (think a microwave oven).

--Bruce

---

From: Bruce Nordman <[email-masked]>
Date: Fri, 11 Mar 2011 16:42:39 -0800

Good discussion.

Batteries are a specific example of a case in which a device has a secondary
function which can consume significant amounts of power, and the secondary
function is independent of the primary one.  My computer is an iMac with an
integrated display, so the display is secondary to the primary function of
computation,
but unlike the battery, its function is not independent (display always
powered
down when the computational part is).

Another example like the battery could be a TV with an integral video
recorder.
The recorder can be active when the TV display is asleep or off.  A third
example
is an imaging MFD that does printing, copying, and scanning; it may have the
scanner active at relatively low power, but the heat-intensive toner fusing
unit
powered down.  Life would be simpler if devices were not multi-functional.

I think we should insist on devices having a primary function (that is
afterall
how "identity" works), and the power state reflects that function.  Simple
devices
with internal batteries can consume a lot of power in sleep or off.  More
sophisticated
devices may choose to use the eman features for exposing the consumption of
the
battery and balance of the system, and then have a state for the batter
exposed.
We need to enable this but not require it.

I am assuming that we will usually have both power state and current power
draw in watts, so the NMS will look at both (and the product's identity) in
deciding what is going on.  (Perhaps part of identity is reporting if a
non-trivial
battery is present (though this can be a dynamic characteristic).)
So, one can look at power level, at power state, or both.  I think having
both addresses Rolf's concerns.

For Juergen's note about the states of off-but charging (so high power),
and on (and presumably AC-connected) but running only off of battery power
(so no AC draw), that confirms the need to have the actual mains power
level.  There have been notebook PCs designed to go off-grid in the
afternoon
to avoid times of high electricity demand, so this is a very real scenario.

More important from my point of view, is that no one on this thread has
jumped
to the defense of ACPI/DMTF.  I am more convinced than ever that they are
a distraction for our purposes.

--Bruce

---

From: "Chris Verges" <[email-masked]>
Date: Fri, 11 Mar 2011 17:07:03 -0800

Hi Bruce,

Please don't take silence as a form of acceptance.  That's a dangerous assumption.

My position is that a single state mechanism is not appropriate for EMAN to consider.  EMAN should support multiple state mechanisms, that coexist with each other.

Consider the following scenario:

Three forms of state management: ACPI, DMTF, and PDU State Management.  (PDU states include on, off, reboot, tripped, and shed.  Only for example purposes, exact details to be worked out later.)

server-a - supports ACPI only

server-b - supports ACPI and DMTF

PDU - supports EMAN PDU State Management

I propose that we allow each device to support the modality that makes sense for that device.  The key is not in which modality is supported, but rather how the user accesses the modality.  Why would we try to limit innovation by restricting what people can do?

Expose different hooks to allow a user to access ACPI, DMTF, and/or PDU State Management through three different interfaces:

emanStateControlAcpi - implemented by entities which know how to respond to ACPI states

emanStateControlDmtf - implemented by entities which know how to respond to DMTF states

emanStateControlPdu - implemented by entities which know how to respond to PDU State Management

This makes the EMAN schema more powerful and allows the market to adapt easily as future changes in technologies and our understanding of how to use those technologies improves.

Chris

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bruce Nordman
Sent: Friday, March 11, 2011 4:43 PM
To: Rolf Winter
Cc: eman mailing list
Subject: Re: [eman] Power states - time to dump ACPI and DMTF

Good discussion.

Batteries are a specific example of a case in which a device has a secondary
function which can consume significant amounts of power, and the secondary
function is independent of the primary one.  My computer is an iMac with an
integrated display, so the display is secondary to the primary function of computation,
but unlike the battery, its function is not independent (display always powered
down when the computational part is).

Another example like the battery could be a TV with an integral video recorder.
The recorder can be active when the TV display is asleep or off.  A third example
is an imaging MFD that does printing, copying, and scanning; it may have the
scanner active at relatively low power, but the heat-intensive toner fusing unit
powered down.  Life would be simpler if devices were not multi-functional.

I think we should insist on devices having a primary function (that is afterall
how "identity" works), and the power state reflects that function.  Simple devices
with internal batteries can consume a lot of power in sleep or off.  More sophisticated
devices may choose to use the eman features for exposing the consumption of the
battery and balance of the system, and then have a state for the batter exposed.
We need to enable this but not require it.

deciding what is going on.  (Perhaps part of identity is reporting if a non-trivial

level.  There have been notebook PCs designed to go off-grid in the afternoon

More important from my point of view, is that no one on this thread has jumped
to the defense of ACPI/DMTF.  I am more convinced than ever that they are
a distraction for our purposes.

--Bruce

Hi,

Best,

Rolf

---

From: "Chris Verges" <[email-masked]>
Date: Sat, 12 Mar 2011 16:59:29 -0800

Sure, the RTC/BIOS battery, UPS systems, etc.  Google even modified a plain server to include a 12VDC battery:

http://news.cnet.com/8301-1001_3-10209580-92.html

Chris

From: Ted Ghose [mailto:[email-masked]] 
Sent: Saturday, March 12, 2011 1:42 PM
To: Chris Verges
Cc: Ted Ghose; Rolf Winter; Bruce Nordman; eman mailing list
Subject: Re: [eman] Power states - time to dump ACPI and DMTF

Servers have batteries? 

-tg-

Sent from my iPhone

On Mar 11, 2011, at 8:04 AM, "Chris Verges" <[email-masked]> wrote:

	Hi Ted,

	I might be putting words into Rolf’s mouth, but here are my thoughts on this:

	Certain devices, like servers, that contain a Lights Out Management (LOM) card will be able to report the server’s power supply as “off” but the battery as “charging”.  This combination for the server entity results in the desired effect.

	Chris

	Hi Rolf, Juergen

	thanks

	-tg-

	Hi,

	

	
	Best,
	
	Rolf

---

From: Ted Ghose <[email-masked]>
Date: Sat, 12 Mar 2011 19:30:49 -0800

servers running on batteries? really?

-tg-

On Fri, Mar 11, 2011 at 8:04 AM, Chris Verges <[email-masked]>wrote:

> Certain devices, like servers, that contain a Lights Out Management (LOM)
> card will be able to report the server’s power supply as “off” but the
> battery as “charging”.  This combination for the server entity results in
> the desired effect.
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Ted Ghose
> *Sent:* Friday, March 11, 2011 8:01 AM
> *To:* Rolf Winter
> *Cc:* Bruce Nordman; eman mailing list
>
> *Subject:* Re: [eman] Power states - time to dump ACPI and DMTF
>
>
>
> Hi Rolf, Juergen
>
>
>
> >       <510-486-7089>510-486-7089
> >       m: <510-501-7943>510-501-7943
> >

---

From: "Chris Verges" <[email-masked]>
Date: Sat, 12 Mar 2011 19:33:00 -0800

I assume you're being rhetorical, but I'll follow up anyway to make sure we all understand your point.  What's so hard to believe about that?  Especially given the examples shown during this discussion.

Thanks,

Chris

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Ghose
Sent: Saturday, March 12, 2011 7:31 PM
To: Chris Verges
Cc: Rolf Winter; Bruce Nordman; eman mailing list
Subject: Re: [eman] Power states - time to dump ACPI and DMTF

-tg-

On Fri, Mar 11, 2011 at 8:04 AM, Chris Verges <[email-masked]> wrote:

Hi Ted,

Chris

Hi Rolf, Juergen

thanks

-tg-

Hi,

Best,

Rolf

---

From: Leonard Tsai <[email-masked]>
Date: Sun, 13 Mar 2011 11:56:39 +0800

There are already 1U server with battery built in. But they also have a service processor on the side. 

Send from iPhone 4G

On 2011/3/13, at 11:33, "Chris Verges" <[email-masked]> wrote:

> I assume you’re being rhetorical, but I’ll follow up anyway to make sure we all understand your point.  What’s so hard to believe about that?  Especially given the examples shown during this discussion.
> 
>  
> 
> Thanks,
> 
> Chris
> 
>  
>

---

From: Rolf Winter <[email-masked]>
Date: Sun, 13 Mar 2011 13:34:36 +0000

Chris, Ted,

I wasn't really implying anything here. To me, it seemed that a lot of the discussion was triggered by the fact that it is difficult to accommodate batteries directly in a device's power state. So I was wondering why one would actually do that (instead of treating it as a completely different entity). My mail tried to summarize the differences and I was asking whether there is more. I believe this is something we want to figure out quickly as a bunch of things will rely on this decision. But it might be that a simple model would work here. E.g. you'd have the state sleep (which means e.g. that the functional components draw little power) and a sub-state that says batteries charging (or not, or which "type" of charging) which tells you that the device as a whole is drawing significant power. The same for on and off states of course. Or you can have all separate in a battery MIB. In either case, I think other battery related information should be in a separate MIB. E.g. whether a battery is fully charged, empty, it's age, number of charging cycles and so forth. So which one should it be, which of the tradeoffs is most important to us?

Best,

Rolf

> From: Chris Verges [mailto:[email-masked]]
> Sent: Freitag, 11. März 2011 17:04
> To: Ted Ghose; Rolf Winter
> Subject: RE: [eman] Power states - time to dump ACPI and DMTF
> 
> Hi Ted,
> 
> 
> 
> Certain devices, like servers, that contain a Lights Out Management
> (LOM) card will be able to report the server's power supply as "off"
> but the battery as "charging".  This combination for the server entity
> results in the desired effect.
> 
> 
> 
> Ted Ghose
> If the device is off, but battery is charging, who is reporting that
> and how? Is battery itself has the intelligence to do so? In that case,
> can we treat it as a separate device independent of the device it is
> connected to, and then we could simplify the model.
> 
> 
> 
> In the other case, though, if device is turned off, there is no one to
> tell what the battery is doing, unless an intelligent PDU or someone is
> aware of that device. Which comes to some source - sink model as well.
> 
> 
> 
> batteries. You either A) try to consider battery state in the devices'
> power state or you B) leave it separate in its own MIB module (as
> described e.g. here http://tools.ietf.org/html/draft-quittek-eman-
> battery-mib-00 where we have battery states full(1),
> partiallyCharged(2), empty(3), charging(4), discharging(5), unknown(6)).
> I think these are the trade-offs:
> 
> order them in a way that a higher state always translates to higher
> power draw. It however seems to complicate power states.
> 
> Option B) If a battery is present, you cannot tell from the device's
> power state whether is it drawing power or not ("off" could be really
> "off but charging"). The device power states can be modelled cleaner
> though and you'd need to look closer to see what the battery state is
> to be sure there is no power draw.
> 
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> London W3 6BL | Registered in England 2832014
> 
> 
> 
> > In this case: Can we map charging/discharging/full/empty to off-
> sleep-
> > on?
> >
> > Thanks,
> >
> >     Juergen
> >
> >

---

From: Juergen Quittek <[email-masked]>
Date: Sun, 13 Mar 2011 21:06:25 +0100

Hi Rolf,

One of the important questions to be answered is:
Do we want to be able to make assumptions on a device's energy consumption based on the power state?
If a devices's power state is off, what would it tell us, if not: The devices does not need any power.

If this is not the case, we are rather talking about functional states with some power-related properties,
But if these states do not serve as basis for power-related assumptions on the device, then the name
POWER state is misleading and not appropriate any more.

Thanks,

    Juergen

---

From: Bruce Nordman <[email-masked]>
Date: Sun, 13 Mar 2011 14:20:17 -0700

I think we are making this more complicated than necessary.
First, our mandate is for monitoring, not control.  We should be
thinking about control (as we are), but should not complicate
the monitoring protocol for control reasons.  I know that eman
will in future be used by some devices for control (and I support
their ability to do so in future), but the great majority I believe will
only use its monitoring features.

Second, the NMS will know the identity of the device being
monitored, so can use that information in drawing conclusions.
The power state does not need to be burdened with trying to
be highly informative by itself.  The device HAS a basic power
state already - we are just trying to expose that which already
exists.

When devices have the ability and need to be more elaborate
in what they communicate (e.g. exposing battery details), we
can facilitate that, but for those that can't or don't need this,
we should allow them to be simple.

Batteries are not involved in the vast majority of electricity
use, and the NMS will know if the device does (or could)
have one and so can draw appropriate conclusions.

To Juergen's question, the assumptions that can be made
about a device's energy based solely on the power state
depends on the device.  We don't need to say more.

--Bruce

On Sun, Mar 13, 2011 at 1:06 PM, Juergen Quittek <[email-masked]> wrote:

> > I wasn't really implying anything here. To me, it seemed that a lot of
> the discussion was triggered by the fact that it is difficult to accommodate
> batteries directly in a device's power state. So I was wondering why one
> would actually do that (instead of treating it as a completely different
> entity). My mail tried to summarize the differences and I was asking whether
> there is more. I believe this is something we want to figure out quickly as
> a bunch of things will rely on this decision. But it might be that a simple
> model would work here. E.g. you'd have the state sleep (which means e.g.
> that the functional components draw little power) and a sub-state that says
> batteries charging (or not, or which "type" of charging) which tells you
> that the device as a whole is drawing significant power. The same for on and
> off states of course. Or you can have all separate in a battery MIB. In
> either case, I think other battery related information should be in a
> separate MIB. E.g. whether a battery is fully charged, empty, it's age,
> number of charging cycles and so forth. So which one should it be, which of
> the tradeoffs is most important to us?
> >
> >
> > Best,
> >
> > Rolf
> >
> ...

---

From: Juergen Quittek <[email-masked]>
Date: Sun, 13 Mar 2011 23:11:42 +0100

Hi Bruce,

I still have the basic question: 
What is the purpose of defining power states?
What do we need them for in addition to functional device states?

We should have a clear answer in the eman WG.

Thanks,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Sun, 13 Mar 2011 23:25:10 +0100

Hi Chris,

I have just a question for clarification: 
What do you call an 'interface'?
Is it just a set of power states, 
such as the set of DMTF power states 
or the set of ACPI power states?
Or is it more than this?

Thanks,

    Juergen

Am 12.03.2011 um 02:07 schrieb Chris Verges:

> Hi Bruce,
>  
> Please don’t take silence as a form of acceptance.  That’s a dangerous assumption.
>  
> server-a – supports ACPI only
> server-b – supports ACPI and DMTF
> PDU – supports EMAN PDU State Management
>  
> emanStateControlAcpi – implemented by entities which know how to respond to ACPI states
> emanStateControlDmtf – implemented by entities which know how to respond to DMTF states
> emanStateControlPdu – implemented by entities which know how to respond to PDU State Management
>

---

From: Bruce Nordman <[email-masked]>
Date: Sun, 13 Mar 2011 15:27:48 -0700

Good question.  I would say we shouldn't try to define power states,
as specific definitions inevitably collide with the wide variety of products
in scope.  Devices already have power states - we are not creating them.
We are only providing a standard way to expose them to the network
(or at least to the NMS).  The distribution of time and energy across
basic power states is always a topic of interest and discussion in
understanding
energy use, and reducing it, whether it is in the context of a single
building, of
technology, or energy policy.  Exposing power state can be a useful
piece of information in how devices interact with each other, in what
this suggests for degrees of network connectivity (including none),
and capability.  Reporting basic power state enables the NMS to use
this information in interpreting the power and energy data.

When specific meaning about a particular product type is intended,
then other mechanisms will usually be called for, whether they are part
of eman or some other protocol.  Creating one or more IANA registries
for functional device states by product type does seem like something
that we should explore.  These would have no expectation of being
universal in the way that power states can be (though harmonization
across product types is certainly to be strived for, particularly for ones
that are more closely related).

--Bruce

---

From: Juergen Quittek <[email-masked]>
Date: Sun, 13 Mar 2011 23:45:32 +0100

Hi Bruce,

I still would prefer having a definition.
The basic motivation is that "if you can't define it, you probably don't know what it is".

Maybe we can say that a power state just indicates the current energy 
consumption POLICY of a device and not necessary its actual consumption 
rate.  Then a sleep mode would be a mode in which a device saves 
energy by not providing major parts of its core function.
 
But this would not necessarily imply that the devices consumes energy 
at a low rate (low power) because the device may charge its batteries 
or do something else that needs significant power.  Still, the device 
saves energy in sleep mode, because its main function is on sleep.
Analogous considerations would apply to the 'off' state.

    Juergen

Am 13.03.2011 um 23:27 schrieb Bruce Nordman:

> basic power states is always a topic of interest and discussion in understanding
> energy use, and reducing it, whether it is in the context of a single building, of

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 14 Mar 2011 00:08:37 +0100

Hi Ted,

> If the device is off, but battery is charging, who is reporting that and how? Is battery itself has the intelligence to do so? In that case, can we treat it as a separate device independent of the…

Yes, Then we need power states for batteries, which may be different to (off, sleep, on).

> In the other case, though, if device is turned off, there is no one to tell what the battery is doing, unless an intelligent PDU or someone is aware of that device. Which comes to some source - sin…

Devices have the capability to notify a management system when they switch power states. 
There is no need for continuous reporting once you reported you're off. A PC may send a 
notification before going to off or sleep mode. And of course it may send a wake-up notification
when waking up from sleep or when booting.

It does not seem to be a smart idea to wake up the device just to report that charging of 
the battery is complete and thus common devices don't do so. But if you measure power 
with an external meter, a management system (or your "parent")  might be able to  detect 
this point in time. Alternatively, you could send a notification to your management system 
(or parent) indicating: I'm going to sleep mode an expect a charging time of 75 minutes.
Then the management system (or parent) could assume (and report) for 75 minutes 
"device in state "sleep with charging batteries" and then switch to plain "sleep".

Thanks,

    Juergen

---

From: "Chris Verges" <[email-masked]>
Date: Sun, 13 Mar 2011 16:34:39 -0700

An interface is an object as described in emanControlTable in draft-verges.  There are multiple objects contained in emanControlTable, one for each type: emanAcpiControl, emanDmtfControl, etc.  An entity can implement one or more interfaces as is understood and supported by the entity.

Proposed additional interfaces could be emanBatteryControl and emanPduControl, for example.

An entity might implement multiple interfaces at the same time.  How the entity chooses to handle this is up to the entity and what makes sense for the entity.  In the case of ACPI and DMTF, the linkage between these is defined by the DMTF standard and should be observed.

Thanks,

Chris

-- 

Chris Verges

408-500-2377

http://www.cyberswitching.com <http://www.cyberswitching.com/> 

From: Juergen Quittek [mailto:[email-masked]] 
Sent: Sunday, March 13, 2011 3:25 PM
To: Chris Verges
Cc: Bruce Nordman; Rolf Winter; eman mailing list
Subject: Re: [eman] Power states - time to dump ACPI and DMTF

Hi Chris,

Or is it more than this?

Thanks,

    Juergen

Hi Bruce,

Chris

Good discussion.

--Bruce

Hi,

Best,

Rolf

---

From: "John Parello (jparello)" <[email-masked]>
Date: Sun, 13 Mar 2011 17:33:32 -0700

Hi Bruce,

Agree our mandate is for monitoring. I've brought up the scenario a few times about how state of a device is needed to monitor.

How can that be addressed in your suggested model?

Thanks
Jp

-----Original Message-----
From: [email-masked] on behalf of Bruce Nordman
Sent: Sun 3/13/2011 2:20 PM
To: Juergen Quittek
Cc: eman mailing list; Rolf Winter
Subject: Re: [eman] Power states - time to dump ACPI and DMTF

--Bruce

---

From: Ted Ghose <[email-masked]>
Date: Mon, 14 Mar 2011 00:03:14 -0700

Hi Juergen

Yes, then I agree to what you are saying. Can we not just solve it by
defining states like

0 - device off not charging
1 - device off charging
:::::::

and we could exactly follow your method when and how to report

thanks

-tg-

On Sun, Mar 13, 2011 at 4:08 PM, Juergen Quittek <[email-masked]> wrote:

> On Fri, Mar 11, 2011 at 5:36 AM, Rolf Winter <[email-masked]>wrote:
>
>> Hi,
>>
>> here http://tools.ietf.org/html/draft-quittek-eman-battery-mib-00 where
>> we have battery states full(1), partiallyCharged(2), empty(3), charging(4),

---

From: Ted Ghose <[email-masked]>
Date: Sat, 12 Mar 2011 13:42:14 -0800

Servers have batteries? 

-tg-

Sent from my iPhone

---

From: Rolf Winter <[email-masked]>
Date: Mon, 14 Mar 2011 08:38:07 +0000

Hi,

not sure policy is the right word. The power state refers to the actual consumption for a device's primary function. Secondary functions could still consume energy. E.g. battery charging or a fan still cooling down a device that was just powered off and others.

Best,

Rolf

> Sent: Sonntag, 13. März 2011 23:46
> To: Bruce Nordman
> 				Do we want to be able to make assumptions on a
> device's energy consumption based on the power state?
> 				If a devices's power state is off, what would
> it tell us, if not: The devices does not need any power.
> 
> 				If this is not the case, we are rather talking
> about functional states with some power-related properties,
> 				But if these states do not serve as basis for
> power-related assumptions on the device, then the name
> 				> I wasn't really implying anything here. To me,
> it seemed that a lot of the discussion was triggered by the fact that
> it is difficult to accommodate batteries directly in a device's power
> state. So I was wondering why one would actually do that (instead of
> treating it as a completely different entity). My mail tried to
> summarize the differences and I was asking whether there is more. I
> believe this is something we want to figure out quickly as a bunch of
> things will rely on this decision. But it might be that a simple model
> would work here. E.g. you'd have the state sleep (which means e.g. that
> the functional components draw little power) and a sub-state that says
> batteries charging (or not, or which "type" of charging) which tells
> you that the device as a whole is drawing significant power. The same
> for on and off states of course. Or you can have all separate in a
> battery MIB. In either case, I think other battery related information
> should be in a separate MIB. E.g. whether a battery is fully charged,
> empty, it's age, number of charging cycles and so forth. So which one
> should it be, which of the tradeoffs is most important to us?
> 				>
> 				>
> 				> Best,
> 				>
> 				> Rolf
> 				>
> 				> NEC Europe Limited | Registered Office: NEC
> House, 1 Victoria Road, London W3 6BL | Registered in England 2832014
> 				...
> 
> 
> 
> 
> 
> 
> 			--
> 			Bruce Nordman

---

From: "John Parello (jparello)" <[email-masked]>
Date: Mon, 14 Mar 2011 07:39:03 -0700

Hi Bruce,

""
""

I don't think those models are a distraction. They represent states of devices that humans are familiar with. Even down to consumers the concept of sleep, hibernate etc are well known and in the vernacular of human interaction with machines / things that use electrical power.

I can't see how we can ignore the existence of these concepts or the enumerations of them from those two bodies. 

As part of our charter we have to work with other standards bodies and this is the direct areas of intersection. I can't see dumping them. We would have to address them and comment at the least - even if the group said ignore them.

IMO they are helpful just not sufficient.

Jp

-----Original Message-----
From: [email-masked] on behalf of Chris Verges
Sent: Fri 3/11/2011 5:07 PM
To: Bruce Nordman; Rolf Winter
Cc: eman mailing list
Subject: Re: [eman] Power states - time to dump ACPI and DMTF
 
Hi Bruce,

Chris

Good discussion.

--Bruce

Hi,

Best,

Rolf

---

From: Rolf Winter <[email-masked]>
Date: Mon, 14 Mar 2011 14:56:47 +0000

John,

I agree with you that ACPI and DMTF shouldn't be ignored. I think it is a requirement that the EMAN product needs to accommodate these states. On the other hand, I think they should not limit us either.

Best,

Rolf

> From: John Parello (jparello) [mailto:[email-masked]]
> Sent: Montag, 14. März 2011 15:39
> To: Chris Verges; Bruce Nordman; Rolf Winter
> Cc: eman mailing list
> I don't think those models are a distraction. They represent states of
> devices that humans are familiar with. Even down to consumers the
> concept of sleep, hibernate etc are well known and in the vernacular of
> human interaction with machines / things that use electrical power.
> 
> I can't see how we can ignore the existence of these concepts or the
> enumerations of them from those two bodies.
> 
> As part of our charter we have to work with other standards bodies and
> this is the direct areas of intersection. I can't see dumping them. We
> would have to address them and comment at the least - even if the group
> said ignore them.
> 
> My position is that a single state mechanism is not appropriate for
> EMAN to consider.  EMAN should support multiple state mechanisms, that
> coexist with each other.
> 
> 
> 
> Three forms of state management: ACPI, DMTF, and PDU State Management.
> (PDU states include on, off, reboot, tripped, and shed.  Only for
> example purposes, exact details to be worked out later.)
> 
> 
> 
> I propose that we allow each device to support the modality that makes
> sense for that device.  The key is not in which modality is supported,
> but rather how the user accesses the modality.  Why would we try to
> limit innovation by restricting what people can do?
> 
> 
> 
> Expose different hooks to allow a user to access ACPI, DMTF, and/or PDU
> State Management through three different interfaces:
> 
> 
> 
> This makes the EMAN schema more powerful and allows the market to adapt
> easily as future changes in technologies and our understanding of how
> to use those technologies improves.
> 
> 
> 
> Chris
> 
> 
> 
> 
>

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Tue, 15 Mar 2011 08:16:57 -0500

Hi,

I also concur that ACPI and DMTF are not distractions.  ACPI has been implemented has been across many computer vendors. 

If those ACPI compliant devices are energy aware devices,  then the WG framework should accommodate these power state models.  

The control framework seems to be different (or proprietary)  from vendor to vendor (IBM, HP, ...) but the power state knobs seem to be common across set of homogenous devices. 

I shall address the other question on the value of power state for monitoring or for control in another email. 

Thanks

Mouli

From: [email-masked] [mailto:[email-masked]] On Behalf Of John Parello (jparello)
Sent: Monday, March 14, 2011 8:09 PM
To: Chris Verges; Bruce Nordman; Rolf Winter
Cc: eman mailing list
Subject: Re: [eman] Power states - time to dump ACPI and DMTF

Hi Bruce,

""

Jp

-----Original Message-----
From: [email-masked] on behalf of Chris Verges
Sent: Fri 3/11/2011 5:07 PM
To: Bruce Nordman; Rolf Winter
Cc: eman mailing list
Subject: Re: [eman] Power states - time to dump ACPI and DMTF

Hi Bruce,

Chris

Good discussion.

--Bruce

Hi,

Best,

Rolf

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Tue, 15 Mar 2011 08:47:31 -0500

Hi Juergen,

Excellent question to get to the root of the problem.  

If the focus is pure monitoring of energy-aware devices, then it is
possible to collect the power meter reading (Watts, volts, ..) of the
device. 

However, much more information about the attributes of the measurement
(the identity of the device, power source, power quality, measurement
caliber, ...) is also provided in the MIB. modules.   

Power states functionality if available for the device is an additional
attribute of the measurement of the device. for e.g.  in addition to
reporting  120 watts, the device is in power state 3.   

The transition to lower power states may occur in a distributed manner;
analogous to the way my Laptop LCD screen shuts-off, during long periods
of inactivity. 

In addition to the power consumption, power state information is also an
additional useful data point. 

Thanks

Mouli

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Juergen Quittek
Sent: Monday, March 14, 2011 3:42 AM
To: Bruce Nordman
Cc: eman mailing list; Rolf Winter
Subject: Re: [eman] Power states - time to dump ACPI and DMTF

Hi Bruce,

Thanks,

    Juergen

--Bruce

On Sun, Mar 13, 2011 at 1:06 PM, Juergen Quittek <[email-masked]>
wrote:

Hi Rolf,

One of the important questions to be answered is:
Do we want to be able to make assumptions on a device's energy
consumption based on the power state?
If a devices's power state is off, what would it tell us, if not: The
devices does not need any power.

If this is not the case, we are rather talking about functional states
with some power-related properties,
But if these states do not serve as basis for power-related assumptions
on the device, then the name
POWER state is misleading and not appropriate any more.

Thanks,

   Juergen

> I wasn't really implying anything here. To me, it seemed that a lot of
the discussion was triggered by the fact that it is difficult to
accommodate batteries directly in a device's power state. So I was
wondering why one would actually do that (instead of treating it as a
completely different entity). My mail tried to summarize the differences
and I was asking whether there is more. I believe this is something we
want to figure out quickly as a bunch of things will rely on this
decision. But it might be that a simple model would work here. E.g.
you'd have the state sleep (which means e.g. that the functional
components draw little power) and a sub-state that says batteries
charging (or not, or which "type" of charging) which tells you that the
device as a whole is drawing significant power. The same for on and off
states of course. Or you can have all separate in a battery MIB. In
either case, I think other battery related information should be in a
separate MIB. E.g. whether a battery is fully charged, empty, it's age,
number of charging cycles and so forth. So which one should it be, which
of the tradeoffs is most important to us?