Subject: [eman] States and Levels

From: Bruce Nordman <[email-masked]>
Date: Wed, 10 Oct 2012 00:32:52 -0700

We have spent much time trying to clarify and disentangle states
and levels for devices.  It seems clear that some applications and
several external standards require grid curtailment levels.
Several long-standing industry standards define device internal
power states.

I took the relevant sections of the framework draft, beginning with 6.5,
and boiled down the text there to what I think covers what we need.
That is shown below.  The existing language was retained as much
as possible.  I did remove redundant text as well as details outside the
scope of the framework and some details from the external standards.

The intent was to not change the meaning of these sections, just the
presentation, except to clarify the difference between  power states
and curtailment levels.

 6.5. Power States

 An Energy Object can be controlled by setting it to a specific Power State
or a specific Curtailment Level (these described in the following section).
 A Power States Set is an interface by which an Energy Object can be
controlled.  Each Energy Object should indicate the Power State Sets that
it implements.  Well known Power State Sets should be registered with IANA

When a device is set to a particular Power State, it may be busy.  The
device will set the desired Power State and then update the actual Power
State when it changes.  There are thus two Power State variables: actual
and desired.

There are many existing standards for and implementations of Power State
Sets.  An Energy Object can support multiple Power State Sets concurrently.

This framework identifies three initial Power State Sets: IEEE1621
[IEEE1621], DMTF [DMTF], and PWG [PWG].
6.5.1 IEEE1621 Power State Set

IEEE1621 [IEEE1621] defines three basic power states : on, off, and sleep.
6.5.2 DMTF Power State Set

DMTF [DMTF] builds on ACPI states defines 6 core power states: On
(ACPI-S0), Sleep-Light (ACPI-S1 or –S2), Sleep-Deep (ACPI-S4), Off-Hard
(ACPI-S5), Off-Soft (ACPI-S5), and Hibernate (ACPI-S4).  It also defines
transitional states and state change commands: PowerCycle Off-Soft,
PowerCycle, MasterBus reset, Diagnostic Interrupt, Off-Soft-Graceful,
Off-Hard Graceful, MasterBus reset Graceful, Power-Cycle Off-Soft Graceful,
and PowerCycle-Hard Graceful.  The DMTF standard is targeted to hosts and
computers.
6.5.3 PWG Power State Set

The Printer Working Group [PWG] also builds on ACPI states defines 6 stable
power states, a series of DMTF “special” power states, a few out-of-band
power states, and provision for vendor extensions to power states.  The
DMTF standard is targeted to printers and other imaging devices.

6.6 Curtailment Levels

EMAN defines curtailment levels to provide a standard approach to model the
different levels of power of a device.  The curtailment levels incorporate
non-operational states as defined in [ACPI] and [DMTF] standards, and
specify several intermediate operational states.

There are twelve curtailment levels: six operational and six
non-operational.  The lowest non-operational level is 1 and the highest is
6.  Each non-operational level corresponds to an ACPI global and system
state.  Each operational state represents a performance state, and may be
mapped to an ACPI processor state.

For each level, the level preceding it is expected to have a lower Power
value.  For levels where the device is non-operational, it is expected that
it has a longer delay in returning to an operational state.

Characteristics of curtailment levels are as follows.  For the first six,
no energy object features are available, except for 4, 5, and 6, which may
include out-of-band management and device wakeup.

mechoff(1): No energy is consumed.  The power connector can be
removed.  Corresponds
to ACPI state G3.

softoff(2): Some components remain powered.  No context is saved.  Powering
up typically requires a system boot.  Corresponds to ACPI state G2/S5.

hibernate(3): The device may be woken without requiring a system boot.  The
time for availability is longer than sleep(4).  Corresponds to ACPI state
G1/S4.

sleep(4): The time for availability is longer than standby(5).  Corresponds
to ACPI state G1/S3.

standby(5): The time for availability is longer than ready(6).  Corresponds
to ACPI state G1/S2.

ready(6):  The device can be quickly transitioned into an operational state.
Corresponds to ACPI state G1/S1.

For all of the following levels, some features may not be available and
power consumption is less than higher numbered levels.  All correspond to
ACPI S0.  The highest power consumption occurs in high(12).  These levels
are:  lowMinus(7), low(8), mediumMinus(9), medium(10), highMinus(11), and
high(12).

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

---

From: Ira McDonald <[email-masked]>
Date: Wed, 10 Oct 2012 17:58:20 -0400

Hi Bruce,

Two corrections to the paragraph on PWG Power States,
w/ highlighted changed words below:

The Printer Working Group [PWG] also builds on ACPI states and defines 6
stable power states, a series of DMTF “special” power states, a few
out-of-band power states, and provision for vendor extensions to power
states.  The PWG standard is targeted to printers and other imaging
devices.

Cheers,
- Ira (editor of PWG Power MIB)

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:[email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434
Temporary Cabin *** 2012 only *** 906-494-2523

On Wed, Oct 10, 2012 at 3:32 AM, Bruce Nordman <[email-masked]> wrote:

> The Printer Working Group [PWG] also builds on ACPI states defines 6
> stable power states, a series of DMTF “special” power states, a few
> out-of-band power states, and provision for vendor extensions to power
> states.  The DMTF standard is targeted to printers and other imaging
> devices.
>
>
> 6.6 Curtailment Levels
>
> EMAN defines curtailment levels to provide a standard approach to model
> the different levels of power of a device.  The curtailment levels
> incorporate non-operational states as defined in [ACPI] and [DMTF]
> standards, and specify several intermediate operational states.
>
> non-operational.  The lowest non-operational level is 1 and the highest
> is 6.  Each non-operational level corresponds to an ACPI global and
> system state.  Each operational state represents a performance state, and
> may be mapped to an ACPI processor state.
>
> value.  For levels where the device is non-operational, it is expected
> that it has a longer delay in returning to an operational state.
>
> mechoff(1): No energy is consumed.  The power connector can be removed.  Corresponds
> to ACPI state G3.
>
> ready(6):  The device can be quickly transitioned into an operational
> state.  Corresponds to ACPI state G1/S1.
>
> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman
>
>

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 15 Oct 2012 06:16:04 +0000

Hi Bruce and all,

Thanks for the proposal. I still have two problems with it.
One is clarity of the term "curtailment levels" and the
other one is a conflict with ASHRAE standards.

What I miss is a clearer differentiation between power level
and curtailment level. Since this document is the place where the
EMAN document set explains what these are, I would rather like to
see more elaboration, particularly on the semantics of curtailment
levels.

Beyond this, I see a conflict with the ASHRAE 201 specification.
Our separation of 'power state' and 'curtailment level' appears
to be conflicting with their very clear ASHRAE specification:

What we call "power state" seems to be an ASHRAE "curtailment level".
ASHRAE 201 gives examples curtailment levels
for lights : 'on', 'dimmed', 'off'
and for a fan: 'high', medium', 'low' and 'off'.
For ASHRAE, there are no fixed sets of curtailment levels. They rather
state that curtailment levels shall be defined and named consistent
with the operation of an entity. If we separate curtailment from
power state, we may not be in line anymore with ASHRAE.

However,  instead of using curtailment levels, ASHRAE also allows
explicit setting of curtailment by specifying absolute or relative
(percentage) power values.

Thanks,
    Juergen

On 10.10.12 09:32, "Bruce Nordman" <[email-masked]<mailto:[email-masked]>> wrote:

6.5. Power States
An Energy Object can be controlled by setting it to a specific Power State or a specific Curtailment Level (these described in the following section).  A Power States Set is an interface by which an Energy Object can be controlled.  Each Energy Object should indicate the Power State Sets that it implements.  Well known Power State Sets should be registered with IANA
When a device is set to a particular Power State, it may be busy.  The device will set the desired Power State and then update the actual Power State when it changes.  There are thus two Power State variables: actual and desired.
There are many existing standards for and implementations of Power State Sets.  An Energy Object can support multiple Power State Sets concurrently.
This framework identifies three initial Power State Sets: IEEE1621 [IEEE1621], DMTF [DMTF], and PWG [PWG].
6.5.1 IEEE1621 Power State Set
IEEE1621 [IEEE1621] defines three basic power states : on, off, and sleep.
6.5.2 DMTF Power State Set
DMTF [DMTF] builds on ACPI states defines 6 core power states: On (ACPI-S0), Sleep-Light (ACPI-S1 or –S2), Sleep-Deep (ACPI-S4), Off-Hard (ACPI-S5), Off-Soft (ACPI-S5), and Hibernate (ACPI-S4).  It also defines transitional states and state change commands: PowerCycle Off-Soft, PowerCycle, MasterBus reset, Diagnostic Interrupt, Off-Soft-Graceful, Off-Hard Graceful, MasterBus reset Graceful, Power-Cycle Off-Soft Graceful, and PowerCycle-Hard Graceful.  The DMTF standard is targeted to hosts and computers.
6.5.3 PWG Power State Set
The Printer Working Group [PWG] also builds on ACPI states defines 6 stable power states, a series of DMTF “special” power states, a few out-of-band power states, and provision for vendor extensions to power states.  The DMTF standard is targeted to printers and other imaging devices.

6.6 Curtailment Levels
EMAN defines curtailment levels to provide a standard approach to model the different levels of power of a device.  The curtailment levels incorporate non-operational states as defined in [ACPI] and [DMTF] standards, and specify several intermediate operational states.
There are twelve curtailment levels: six operational and six non-operational.  The lowest non-operational level is 1 and the highest is 6.  Each non-operational level corresponds to an ACPI global and system state.  Each operational state represents a performance state, and may be mapped to an ACPI processor state.
For each level, the level preceding it is expected to have a lower Power value.  For levels where the device is non-operational, it is expected that it has a longer delay in returning to an operational state.
Characteristics of curtailment levels are as follows.  For the first six, no energy object features are available, except for 4, 5, and 6, which may include out-of-band management and device wakeup.
mechoff(1): No energy is consumed.  The power connector can be removed.  Corresponds to ACPI state G3.
softoff(2): Some components remain powered.  No context is saved.  Powering up typically requires a system boot.  Corresponds to ACPI state G2/S5.
hibernate(3): The device may be woken without requiring a system boot.  The time for availability is longer than sleep(4).  Corresponds to ACPI state G1/S4.
sleep(4): The time for availability is longer than standby(5).  Corresponds to ACPI state G1/S3.
standby(5): The time for availability is longer than ready(6).  Corresponds to ACPI state G1/S2.
ready(6):  The device can be quickly transitioned into an operational state.  Corresponds to ACPI state G1/S1.
For all of the following levels, some features may not be available and power consumption is less than higher numbered levels.  All correspond to ACPI S0.  The highest power consumption occurs in high(12).  These levels are:  lowMinus(7), low(8), mediumMinus(9), medium(10), highMinus(11), and high(12).

--
Bruce Nordman
Lawrence Berkeley National Laboratory
nordman.lbl.gov<http://nordman.lbl.gov>
[email-masked]<mailto:[email-masked]>
510-486-7089
m: 510-501-7943

_______________________________________________ eman mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/eman

---

From: Brad Schoening <[email-masked]>
Date: Tue, 16 Oct 2012 20:13:35 -0500

Juergen,

You mention below using absolute or relative (percentage) power levels.  There are no doubt valuable use cases for devices with a linear relationship between power consumed and effective work, such as perhaps motors or an air conditioner.

However, percentages are less useful for 'bursty' workloads found in the data center such as printers or dedicated servers.   What would be the utility of setting a absolute power limit on a printer that rendered it incapable of printing?  Likewise, in the past we've related our discussions with Intel regarding their "race to finish" philosophy – it's more efficient for a CPU to run at high speed to finish calculations and then enter a pause state, rather than run at a steady but reduced frequency.

Finally, idle states are something we haven't discussed much, but they're discussed In Nedevschi, et al. "Skilled in the Art of Being Idle:
Reducing Energy Waste in Networked Systems".   This paper presents four basic power states:  off, sleep, idle, full-on.

When looking at ASHRAE, ACPI, DMTF, or IEC 621 what we see is a variety of models, incorporating some notion of graduated levels.  I believe our utilization of an IANA registry will support all of these.

Regards,

Brad

Brad Schoening
Engineering | Coraid
Tel: +1 917 304 7190
[email-masked] | www.coraid.com<http://www.coraid.com>
Coraid: Redefining Storage

From: Juergen Quittek <[email-masked]<mailto:[email-masked]>>
Date: Mon, 15 Oct 2012 01:16:04 -0500
To: Bruce Nordman <[email-masked]<mailto:[email-masked]>>, eman mailing list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [eman] States and Levels

Hi Bruce and all,

Thanks,
    Juergen

6.5. Power States

6.6 Curtailment Levels

---

From: Daniel Kharitonov <[email-masked]>
Date: Wed, 17 Oct 2012 01:29:41 +0000

This would be exactly my concern.

States are better expressed in functionality levels because this is what drives usability.

Expected power figures are estimates (at best) and have little meaning to end users.

________________________________
From: [email-masked] on behalf of Brad Schoening
Sent: Tuesday, October 16, 2012 6:13:35 PM
To: Juergen Quittek; Bruce Nordman; eman mailing list
Subject: Re: [eman] States and Levels

Juergen,

Regards,

Brad

Brad Schoening
Engineering | Coraid
Tel: +1 917 304 7190

Hi Bruce and all,

Thanks,
    Juergen

6.5. Power States

6.6 Curtailment Levels

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 17 Oct 2012 16:31:17 +0000

Hi Bruce,

Below please find an alternative proposal, that I consider simpler
an more open.  The basic idea is that any power state or
curtailment Level defined by other standards is referred to as
Power State and registered in the same plain IANA registry.
Specification of power state semantics may vary from State
to State according to points a)-c) below.  Energy Objects may
implement any possible subset of registered states.

Thanks,
    Juergen

6.5. Power States

An Energy Object can be controlled by setting it to a specific
Power State.  An Object implements a set of power states consiting
of al least two states, an on stae and an off state.

A Power State is an interface by which an Energy Object can be
controlled.  Each Energy Object should indicate the set of Power
States that it implements.  Well known Power States should be
registered with IANA.  When a device is set to a particular Power
State, it may be busy.  The device will set the desired Power State
and then update the actual Power State when it changes.  There are
thus two Power State variables: actual and desired.

There are many existing standards for and implementations of Power
Stats.  An Energy Object can support a mixed set of power states
defined in different standards, A basic example is gien by the three
Power States defined in IEEE1621 [IEEE1621]: on, off, and sleep.
The DMTF [DMTF], ACPI [ACPI], and PWG [PWG] define larger numbers
of Power States.

The semantics of a power state is specified by either
  a) the functionality provided by an energy object in this state
  b) a limitation of the power that an energy object uses in this
     state
  c) a combination of a) and b)

The semantics of a power state should be clearly defined.  Power
limitation (curtailment) of the power used by an energy object in
a state can be specified by
  - an absolute power value
  - a percentage value of power relative to the energy object's
    nameplate power,
  - an indication of used power relative to another power state,
    for example, by stating used power in state A is less than in
    state B.

Pwer states can be registered at IANA with a description of their
semantics.  An Energy Object must indicate which subset of all
power states it implements.

On 10.10.12 09:32, "Bruce Nordman" <[email-masked]> wrote:

>6.5. Power States An Energy Object can be controlled by setting it
>to a specific Power State or a specific Curtailment Level (these
>described in
>the following section).  A Power States
>Set is an interface by which an Energy Object can be controlled.  Each
>Energy Object should indicate the Power
>State Sets that it implements.  Well
>known Power State Sets should be registered with IANA
>When a device is set to a
>particular Power State, it may be busy.
>The device will set the desired Power State and then update the actual
>Power State when it changes.  There are
>thus two Power State variables: actual and desired.
>There are many existing standards
>for and implementations of Power State Sets.
>An Energy Object can support multiple Power State Sets concurrently.
>This framework identifies three initial
>Power State Sets: IEEE1621 [IEEE1621], DMTF [DMTF], and PWG [PWG].
>6.5.1 IEEE1621 Power State SetIEEE1621 [IEEE1621] defines three
>basic power states : on, off, and sleep.
>6.5.2 DMTF Power State SetDMTF [DMTF] builds on ACPI states
>defines 6 core power states: On (ACPI-S0), Sleep-Light (ACPI-S1 or S2),
>Sleep-Deep
>(ACPI-S4), Off-Hard (ACPI-S5), Off-Soft (ACPI-S5), and Hibernate
>(ACPI-S4).  It also defines transitional states and state
>change commands: PowerCycle Off-Soft, PowerCycle, MasterBus reset,
>Diagnostic
>Interrupt, Off-Soft-Graceful, Off-Hard Graceful, MasterBus reset
>Graceful, Power-Cycle
>Off-Soft Graceful, and PowerCycle-Hard Graceful.  The DMTF standard is
>targeted to hosts and
>computers.  
>6.5.3 PWG Power State SetThe Printer Working Group [PWG] also
>builds on ACPI states defines 6 stable power states, a series of DMTF
>³special²
>power states, a few out-of-band power states, and provision for vendor
>extensions to power states.  The DMTF
>standard is targeted to printers and other imaging devices.
> 
>6.6 Curtailment LevelsEMAN defines curtailment levels
>to provide a standard approach to model the different levels of power of a
>device.  The curtailment levels
>standards, and
>There are twelve curtailment
>levels: six operational and six non-operational.  The lowest
>non-operational level is 1 and the
>highest is 6.  Each non-operational level
>corresponds to an ACPI global and system state.
>Each operational state represents a performance state, and may be mapped
>to an ACPI processor state.
>For each level, the level
>preceding it is expected to have a lower Power value.  For levels where
>the device is
>non-operational, it is expected that it has a longer delay in returning
>to an
>operational state.
>Characteristics of curtailment
>levels are as follows.  For the first
>six, no energy object features are available, except for 4, 5, and 6,
>which may
>softoff(2): Some components
>remain powered.  No context is saved.  Powering up typically requires a
>system boot.
> Corresponds to ACPI state G2/S5.
>sleep(4): The time for
>availability is longer than standby(5).  Corresponds
>to ACPI state G1/S3.
>standby(5): The time for
>availability is longer than ready(6).  Corresponds
>to ACPI state G1/S2.
>ready(6):  The device can be quickly transitioned into an
>operational state.  Corresponds to ACPI state
>G1/S1.
>For all of the following levels,
>some features may not be available and power consumption is less than
>higher
>numbered levels.  All correspond to ACPI
>S0.  The highest power consumption occurs
>in high(12).  These levels are:  lowMinus(7), low(8), mediumMinus(9),
>medium(10), highMinus(11), and high(12).
> 
>
>
>-- 
>Bruce Nordman
>nordman.lbl.gov <http://nordman.lbl.gov>
>[email-masked]
>510-486-7089
>m: 510-501-7943
>

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 17 Oct 2012 16:31:11 +0000

Hi Brad,

I agree with you that fixed power values are of limited use for many kinds
of devices.  I just pointed out that ASHRAE is using them.

BTW: There is almost no different between absolute and percentage values.
The only difference is the number space that you use.
It doesn't matter much whether a power state of a device with 200 Watts
nameplate power limits power to an absolute value of 100 Watts or to a
percentage value of 50% nameplate power.

Thanks,
    Juergen

On 17.10.12 03:13, "Brad Schoening" <[email-masked]> wrote:

>Juergen,
>
>
>You mention below using absolute or relative (percentage) power levels.
>There are no doubt valuable use cases for devices with a linear
>relationship between power consumed and effective work, such as perhaps
>motors or an air conditioner.
>
>
>However, percentages are less useful for 'bursty' workloads found in the
>data center such as printers or dedicated servers.   What would be the
>utility of setting a absolute power limit on a printer that rendered it
>incapable of printing?  Likewise, in
> the past we've related our discussions with Intel regarding their "race
>to finish" philosophy  it's more efficient for a CPU to run at high
>speed to finish calculations and then enter a pause state, rather than
>run at a steady but reduced frequency.
>
>
>Finally, idle states are something we haven't discussed much, but they're
>discussed In Nedevschi, et al. "Skilled in the Art of Being Idle:
>Reducing Energy Waste in Networked Systems".   This paper presents four
>basic power states:  off, sleep, idle, full-on.
>
>
>When looking at ASHRAE, ACPI, DMTF, or IEC 621 what we see is a variety
>of models, incorporating some notion of graduated levels.  I believe our
>utilization of an IANA registry will support all of these.
>
>
>Regards,
>
>
>Brad 
>
>
>Brad
> Schoening
>Engineering | Coraid
>Tel: +1 917 304 7190
>[email-masked] | www.coraid.com <http://www.coraid.com>
>From: Juergen Quittek <[email-masked]>
>To: Bruce Nordman <[email-masked]>, eman mailing list <[email-masked]>
>6.5. Power StatesAn
> Energy Object can be controlled by setting it to a specific Power State
>controlled. 
>Each Energy Object should indicate the Power State Sets that it
>implements. 
>Well known Power State Sets should be registered with IANA
>When a device is set to a particular Power State, it may be busy.
>Power State when it changes.
>There are thus two Power State variables: actual and desired.
>Sets. 
>6.5.1 IEEE1621 Power State SetIEEE1621 [IEEE1621] defines three basic
>power states : on, off, and sleep.
>
>6.5.2 DMTF Power State
>SetDMTF [DMTF] builds on ACPI states defines 6 core power states: On
>(ACPI-S0), Sleep-Light (ACPI-S1 or S2), Sleep-Deep (ACPI-S4), Off-Hard
>(ACPI-S5), Off-Soft (ACPI-S5), and Hibernate (ACPI-S4).
>It also defines transitional states and state change commands: PowerCycle
>Off-Soft, PowerCycle, MasterBus reset, Diagnostic Interrupt,
>Off-Soft-Graceful, Off-Hard Graceful, MasterBus reset Graceful,
>Power-Cycle Off-Soft Graceful, and PowerCycle-Hard
> Graceful.  The DMTF standard is targeted to hosts and computers.
>
>6.5.3 PWG Power State SetThe Printer Working Group [PWG] also builds on
>ACPI states defines 6 stable power states, a series of DMTF ³special²
>extensions to power states.
>The DMTF standard is targeted to printers and other imaging devices.
> 
>6.6 Curtailment LevelsEMAN defines curtailment levels to provide a
>standard approach to model the different levels of power of a device.
> The curtailment levels incorporate non-operational states as defined in
>[ACPI] and [DMTF] standards, and specify several intermediate operational
>states.
>
>non-operational. 
>The lowest non-operational level is 1 and the highest is 6.
>Each non-operational level corresponds to an ACPI global and system
>state. 
>value. 
>For levels where the device is non-operational, it is expected that it
>has a longer delay in returning to an operational state.
>Characteristics of curtailment levels are as follows.
>For the first six, no energy object features are available, except for 4,
>5, and 6, which may include out-of-band management and device wakeup.
>mechoff(1): No energy is consumed.
>The power connector can be removed.  Corresponds to ACPI state G3.
>
>softoff(2): Some components remain powered.
>No context is saved.  Powering up typically requires a system boot.
>hibernate(3): The device may be woken without requiring a system boot.
>The time for availability is longer than sleep(4).  Corresponds to ACPI
>state G1/S4.
>power consumption is less than higher numbered levels.
>All correspond to ACPI S0.  The highest power consumption occurs in
>high(12). 
>These levels are:  lowMinus(7), low(8), mediumMinus(9), medium(10),
>highMinus(11), and high(12).
> 
>
>
>-- 
>Bruce Nordman
>_______________________________________________ eman mailing list
>[email-masked] <mailto:[email-masked]>

---

From: "John Parello (jparello)" <[email-masked]>
Date: Wed, 17 Oct 2012 21:12:17 +0000

Hi Juergen,

Thanks so much for the concise proposal. I think that boils down what we have been discussing for quite some time into a clean statement.

I'd like to add a few things so see inline. If you agree or propose something better I can add this as the new section for this draft before the deadline Monday.

See below prefixed by [jp]

Jp

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juergen Quittek
Sent: Wednesday, October 17, 2012 9:31 AM
To: Bruce Nordman; eman mailing list
Subject: Re: [eman] States and Levels

<deletia>

6.5. Power States

An Energy Object can be controlled by setting it to a specific Power State.  An Object implements a set of power states consiting of al least two states, an on stae and an off state.

A Power State is an interface by which an Energy Object can be controlled.  Each Energy Object should indicate the set of Power States that it implements.  Well known Power States should be registered with IANA.  When a device is set to a particular Power State, it may be busy.  The device will set the desired Power State and then update the actual Power State when it changes.  There are thus two Power State variables: actual and desired.

There are many existing standards for and implementations of Power Stats.  An Energy Object can support a mixed set of power states defined in different standards, A basic example is given by the three Power States defined in IEEE1621 [IEEE1621]: on, off, and sleep.
The DMTF [DMTF], ACPI [ACPI], and PWG [PWG] define larger numbers of Power States.

The semantics of a power state should be clearly defined.  Power limitation (curtailment) of the power used by an energy object in a state can be specified by
  - an absolute power value
  - a percentage value of power relative to the energy object's
    nameplate power,
  - an indication of used power relative to another power state,
    for example, by stating used power in state A is less than in
    state B.
[jp] Additional attributes like name,  time in state, counters, time to enter and exit a state, can be specified.

Power states can be registered at IANA with a description of their semantics.  An Energy Object must indicate which subset of all power states it implements.

[jp] When requesting to set to a power state an indication of the state by name, or index can be used. Also a request to enter a state by matching the closest absolute or relative power can be made.

[jp] NOTE: I'd like us to keep the EMAN power States we've had in the draft for some time now in a separate section.  I  recommend that as an IANA registered set as we planned. I have an ecosystem (Cisco EnergyWise) of multiple vendors currently using these since we've found that the existing ones had no operational states like low, medium or high. As a representative of that group, the industrial automation ODVA and working with ASHREA we'd like to have these defined as a common set in IANA.

Thanks!
Jp

On 10.10.12 09:32, "Bruce Nordman" <[email-masked]> wrote:

>We have spent much time trying to clarify and disentangle states and 
>levels for devices.  It seems clear that some applications and several 
>external standards require grid curtailment levels.
>Several long-standing industry standards define device internal power 
>states.
>
>I took the relevant sections of the framework draft, beginning with 
>6.5, and boiled down the text there to what I think covers what we need.
>That is shown below.  The existing language was retained as much as 
>possible.  I did remove redundant text as well as details outside the 
>6.5. Power States An Energy Object can be controlled by setting it to a 
>specific Power State or a specific Curtailment Level (these described 
>in the following section).  A Power States Set is an interface by which 
>an Energy Object can be controlled.  Each Energy Object should indicate 
>the Power State Sets that it implements.  Well known Power State Sets 
>should be registered with IANA When a device is set to a particular 
>Power State, it may be busy.
>Power State when it changes.  There are thus two Power State variables: 
>actual and desired.
>6.5.2 DMTF Power State SetDMTF [DMTF] builds on ACPI states defines 6 
>core power states: On (ACPI-S0), Sleep-Light (ACPI-S1 or S2), 
>Sleep-Deep (ACPI-S4), Off-Hard (ACPI-S5), Off-Soft (ACPI-S5), and 
>Hibernate (ACPI-S4).  It also defines transitional states and state 
>Diagnostic Interrupt, Off-Soft-Graceful, Off-Hard Graceful, MasterBus 
>reset Graceful, Power-Cycle Off-Soft Graceful, and PowerCycle-Hard 
>extensions to power states.  The DMTF standard is targeted to printers 
>and other imaging devices.
> 
>[ACPI] and [DMTF] standards, and specify several intermediate 
>operational states.
>non-operational level is 1 and the highest is 6.  Each non-operational 
>level corresponds to an ACPI global and system state.
>Each operational state represents a performance state, and may be 
>the device is non-operational, it is expected that it has a longer 
>delay in returning to an operational state.
>which may include out-of-band management and device wakeup.
>time for availability is longer than sleep(4).  Corresponds to ACPI 
>state G1/S4.
>sleep(4): The time for
>availability is longer than standby(5).  Corresponds to ACPI state 
>G1/S3.
>standby(5): The time for
>availability is longer than ready(6).  Corresponds to ACPI state G1/S2.
>higher numbered levels.  All correspond to ACPI S0.  The highest power 
>consumption occurs in high(12).  These levels are:  lowMinus(7), 
>low(8), mediumMinus(9), medium(10), highMinus(11), and high(12).
> 
>
>
>--
>Bruce Nordman
>nordman.lbl.gov <http://nordman.lbl.gov> [email-masked]
>510-486-7089
>m: 510-501-7943
>

---

From: Ira McDonald <[email-masked]>
Date: Wed, 17 Oct 2012 17:55:49 -0400

Hi,

+1

Cheers,
- Ira

On Wed, Oct 17, 2012 at 5:12 PM, John Parello (jparello) <[email-masked]
> wrote:

> Hi Juergen,
>
> Thanks so much for the concise proposal. I think that boils down what we
> have been discussing for quite some time into a clean statement.
>
> I'd like to add a few things so see inline. If you agree or propose
> something better I can add this as the new section for this draft before
> the deadline Monday.
>
> An Energy Object can be controlled by setting it to a specific Power
> State.  An Object implements a set of power states consiting of al least
> two states, an on stae and an off state.
>
> A Power State is an interface by which an Energy Object can be controlled.
>  Each Energy Object should indicate the set of Power States that it
> implements.  Well known Power States should be registered with IANA.  When
> a device is set to a particular Power State, it may be busy.  The device
> will set the desired Power State and then update the actual Power State
> when it changes.  There are thus two Power State variables: actual and
> desired.
>
> There are many existing standards for and implementations of Power Stats.
>  An Energy Object can support a mixed set of power states defined in
> different standards, A basic example is given by the three Power States
> defined in IEEE1621 [IEEE1621]: on, off, and sleep.
> limitation (curtailment) of the power used by an energy object in a state
> can be specified by
> [jp] Additional attributes like name,  time in state, counters, time to
> enter and exit a state, can be specified.
>
> Power states can be registered at IANA with a description of their
> semantics.  An Energy Object must indicate which subset of all power states
> it implements.
>
> [jp] When requesting to set to a power state an indication of the state by
> name, or index can be used. Also a request to enter a state by matching the
> closest absolute or relative power can be made.
>
> [jp] NOTE: I'd like us to keep the EMAN power States we've had in the
> draft for some time now in a separate section.  I  recommend that as an
> IANA registered set as we planned. I have an ecosystem (Cisco EnergyWise)
> of multiple vendors currently using these since we've found that the
> existing ones had no operational states like low, medium or high. As a
> representative of that group, the industrial automation ODVA and working
> with ASHREA we'd like to have these defined as a common set in IANA.
>
> Thanks!
> Jp
>
>
>

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 19 Oct 2012 11:30:26 +0000

Hi John,

I see your points.  I tried to modify the proposed text
according to your comments.  Please see inline.

On 17.10.12 23:12, "John Parello (jparello)" <[email-masked]> wrote:

>controlled.  Each Energy Object should indicate the set of Power States
>that it implements.  Well known Power States should be registered with
>IANA.  When a device is set to a particular Power State, it may be busy.

Agreed.  However, "time in state" is not specifying
semantics of a state.  It is about statistics.
We need a separate paragraph for this.  I suggest adding
it after the IANA paragraph below.  Please find a text
proposal there.

>semantics.  An Energy Object must indicate which subset of all power
>states it implements.

Based on John's comment I suggest appending the following
text to the previous paragraph:

   "Power states should be registered at IANA with a name and a
    number.   When requesting an Energy object to enter a power
    state an indication of its name or its number can be used."

Then a new paragraph would be needed for power state statistics:
   "For supporting power state management it is useful to provide
    statistics on power states including the time an Energy Object
    spent in a certain power state and the number of times an
    Energy Object entered a power state."

>[jp] When requesting to set to a power state an indication of the state
>by name, or index can be used.

Agreed.  I used your text in the proposal to append the IANA
paragraph.

>Also a request to enter a state by matching the closest absolute or
>relative power can be made.

This sounds very useful.  However,  do not fully understand
the how it would work.  Could you elaborate or give an example?

>with ASHREA we'd like to have these defined as a common set in IANA.

I think it commonly agreed that we want to support consortia
registering their agreed power states at IANA.  That's much
better than having every organization registering their own
states.  However, having a single company registering power
states should not be excluded.

Text explaining this probably needs to go to the IANA considerations
Section.

Thanks,
    Juergen

---

From: "John Parello (jparello)" <[email-masked]>
Date: Sat, 20 Oct 2012 02:03:53 +0000

Hi Juergen,

Agree with your proposals below. The one item you asked for was an explanation of asking for a power state change based on percent of maximum.

See ashrae for setting curtailment. They have recognized that some device have the ability to work at power levels,specified by percent of maximum.

For example a light may have the simple on,off states but you can control it as a dimmer.

If I ask to go to 0% of max it would turn off. If I ask for 50% of max it would go to the on state. If I later ask for 100% of max it would still remain on.

If this light were Poe powered and had the 5 predefined states, I should be able  to request lighting based on percentages the state should change to the closest.

So say there are 5 states define as state@maximum s.t. 

{1@0W,2@15W,3@20W,4@25W,5@30w}  . 

I should be able to request the light to go,to 50% of maximum and it would show the state as 2. If I ask for 51% of maximum it should show as 3.

That allows control for variable devices as well.

>From experience with our Cisco energy spec we only published states at first and the variable control devices became a problem. So we went with the ashrae type model as well to get this  variable control. Industrial automation has the same dual way of requesting control.

An analogy would be a car radio. I can change the frequency value based on a "dial" or based on a set of presets. Two ways of controlling the same thing. I should be able to set the power based on preset states or a variable "dial" based on percentages.

 If the device cannot support the variable power setting it can opt to go to the closet preset or ignore the request with error/info.

Jp

Sent from my iPad 
(expect ridiculous spelling mistakes)