Subject: [OPSAWG] FW: comment on draft draft-claise-energy-monitoring-mib-03

From: "Rolf Winter" <[email-masked]>
Date: Tue, 8 Jun 2010 20:35:04 +0200

By accident I only replied to Brad, not to the list:

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

-----Original Message-----
From: Rolf Winter 
Sent: Dienstag, 8. Juni 2010 18:26
To: 'Brad Schoening'
Subject: RE: [OPSAWG] comment on draft draft-claise-energy-monitoring-mib-03

Hi Brad,

Leaving automobiles for a minute, to me, there are two main reasons to have power states:

A) equipment that has no instrumentation to report measured power consumption can report a power state and a NMS can deduct what that might mean in terms of power consumption, even if obviously not precisely (this is not defined by ACPI. But I think this is important for an efficient power management strategy unless you're happy knowing that on average you use less power than, say D2, which is what you seem to suggest with your analogy, without knowing what D2 means in practice)

B) the power state is an operational state which can show you things like utilization (i.e. low power state might mean low utilization) and current capabilities (i.e. low power state might mean that the full functionality is not available right now or it might tell you how fast you can get from the current into the another state)

Whatever the power state is, the NMS needs to know what that actually means, i.e. it needs to be configuring with the needed knowledge as ACPI is vague on these issues. The above will also be vastly different from device to device and will evolve over time. Having fixed classes potentially either miss much of the above, or people will start to map their own stuff to these fixed classes over time. In either case the NMS needs to know what all this means as it is not encoded in an ACPI state. Actually, with ACPI you would also need to add the device class on top, which I believe is not part of your MIB. 

Additionally, ACPI had a predecessor (APM) and there might be another one after ACPI or changes to ACPI etc. Having user defined-only states will make the MIB independent from these developments. These states could come spiced up with the information needed by the NMS. Also, some people have expressed a quite different perception of the power states as implemented and proposed in standards. Maybe Bruce Nordman could expand on an earlier Email?

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 Brad Schoening
Sent: Dienstag, 8. Juni 2010 17:19
To: Rolf Winter; [email-masked]
Subject: Re: [OPSAWG] comment on draft draft-claise-energy-monitoring-mib-03

Hi Rolf,

Thanks for your feedback here.

I have to respectfully disagree with your first point that power levels
should match some known measurement of energy consumption in watts or
watt-hrs.  Consider manual transmission cars, which typically have 'levels'
or gears 1-5.  Most drivers don't know the rpm and torque a given gear
delivers, but can happily drive their car or even an unfamiliar rental
knowing that gear one is the lowest, and five the highest, with intermediate
gears 2-3-4.  The engine power provided in 1st gear by a Land Rover vs. an
MG Midget are vastly different, but yet with a meaning crystal clear to that
driver.

In addition to the ACPI standard, I would also ask that you consider the
DMTF Power State Management Profile (DSP1027 -
http://www.dmtf.org/standards/published_documents/DSP1027.pdf) which defines
fixed power levels for on, sleep-light, sleep-deep, off-soft, off-hard.

DSP1027 has a 'PowerStatesSupported' property:

	7.2.3 CIM_PowerManagementCapabilities.PowerStatesSupported
	The PowerStatesSupported property array is used to represent the
power states 
	that are supported by the associated computer system.

PowerStatesSupported works similar to our proposed model, whereby the device
supports a subset of levels defined in the standard.  Indeed, we support all
of the Power State Management Profile levels in our model.

Given that existing devices implement ACPI levels and existing management
standards (DMTF) defining levels, how would using these cause confusion?
Instead, wouldn't we cause confusion if we didn't leverage existing fixed
power levels?

I would very much like to find more use cases here.  Perhaps there are NMS
power management standards that don't define fixed levels, but thus far I'm
not aware of any.

Regards,

Brad

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rolf Winter
Sent: Monday, June 07, 2010 9:02 AM
To: [email-masked]
Subject: [OPSAWG] comment on draft draft-claise-energy-monitoring-mib-03

Hi,

I have a comment on the draft draft-claise-energy-monitoring-mib-03
regarding the power levels which somewhat goes into the direction of an
earlier comment by Bruce Nordman. I personally see little value having a
large number of predefined power-levels if it turns out that these are
either

1. all different in terms of the amount of energy that they consume (across
different devices)
2. do not match what is implemented or ever will be implemented (although
the latter is hard to foresee)
3. need to be mapped to something that is in fact implemented
4. need additional configuration on the NMS side to interpret these levels
correctly

Especially the last point I guess will happen in practice, i.e. the power
state reading needs to be correlated with numbers from e.g. the device data
sheet. If that is the case I would rather have only freely configurable
power levels (which you allow in the draft) rather than having predefined
ones that in practice mean different things and are therefore prone to
misinterpretation. You have an example of where the ACPI states are mapped
to whatever is implemented. I believe instead of being helpful this can be
confusing in practice. Alternatively, a small number of "buckets" as
described by Bruce and freely configurable power levels/modes/states per
bucket are fine too.

Best,

	Rolf

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

_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg