Subject: Re: [OPSAWG] Power MIBs issue #2: number of power states

From: "Rolf Winter" <[email-masked]>
Date: Wed, 5 May 2010 18:03:21 +0200

Hi,

That would be one way of doing it. However, I am not exactly sure what that would buy you. Say you have these 10 defined power levels then you will either need a) instrumentation to measure which of these levels you are in or b) well defined states where you know how much power you draw. a) is no good because with instrumentation you can do statistics which the draft defines. Now, without instrumentation you need to have some kind of power profiles that tell you which of these 10 states you're in. That is (depending on the type of equipment) not easy I guess. So say you have a device that has on/sleep/off states and you want to retrofit that into those 10 states you'd need to somehow constantly monitor which components of the device are being used, for how long etc and calculate back what that could mean in terms of energy consumption. That seems overly complex to me. A device manual would probably give you some information about the different power mode energy consumptions (max/average or similar). In your management backend you could correlate those easily. Effectively you would change the three well known device states for ten device states which you have to work out without instrumentation. You could ask why 10 is better than three in this case or any other arbitrary number. Don't get me wrong, I not saying this is generally a bad idea, just saying it makes matters more complicated and I am not sure that is a price worth paying.

Best,

	Rolf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Ellison
Sent: Mittwoch, 28. April 2010 04:11
To: Juergen Quittek
Cc: [email-masked]; Thomas Dietz; Dominique Dudkowski; Rolf Winter
Subject: Re: [OPSAWG] Power MIBs issue #2: number of power states

Juergen,

I have not studied the Power MIB draft, but after reading several emails WRT power states, I wonder if a somewhat different approach could been considered-

Rather than name some number of power states, would it not be more useful to have a pair of objects- the first to indicate the rated full power consumption draw of a device (volt amps or whatever is appropriate) and the second to provide a rating from 1 through 10, with 10 being full power draw and 1 being minimal power draw (zero would not allow a reply be sent).  

This pair of objects could provide both a relative measure for the device, and a reasonable estimate of the actual power consumed by a device. Further, the accuracy of the values of this pair of objects could be verified by external means, for example by monitoring the power drawn at the outlet for a given device.

Possibly this approach could be considered as an alternative to the named states?

Regards,

Mark

On Fri, Apr 23, 2010 at 4:26 AM, Juergen Quittek <[email-masked]> wrote:

	Issue #2: number of power states
	
	We do not yet have consensus how many power states should be
	supported/standardized.
	
	The Entity State MIB module defines (RFC4268) defines three states:
	unknown(1), hotStandby(2), coldStandby(3), providingService(4) in
	TC EntityStandbyStatus. As the name indicates, the intention of this
	TC is not defining power states, but defining standy states. From
	a power management point of view "hotStandby(2)" and providingService(4)
	may be quite similar.
	
	draft-claise-energy-monitoring-mib-02 defines twelve power states:
	mechoff(1), softoff(2), hibernate(3), sleep(4), standby(5), ready(6),
	low(7), frugal(8), medium(9), reduced(10), high(11), and full(12).
	This may be considered too many???
	
	These twelve states have been derived from the Advanced Configuration
	& Power Interface (ACPI). I talked to people from EnergyStar. They
	consider the ACPI states as too detailed. They told me that to their
	knowledge, several of the ACPI states have not been implemented by
	any device, yet.
	
	The discussion whether 3 8 10 12 or 15 power states are the best
	choice may become tedious and non-productive. We suggest not fixing
	the number of power states in an SMI enumeration, but leave the
	number and names of power states up to the developer of a device
	or of the MIB module, respectively.
	
	In draft-quittek-power-mib-01 we suppoerted this by indexing the
	PowerStateTable by an object of type SnmpAdminString which would
	Carry the name given to a power State and by adding another object
	of the same type (powerStateDescription) for providing a brief
	description of what power reduction measures are applied in this
	State.
	
	This would give a lot of flexibility but has the disadvantage
	that naming of power states may be very different on different devices.
	But having a consistent (fixed) naming would not help much because
	it is impossible to give reasonably clear guidelines in a standards
	document what a power state "medium" would have to be implemented.
	If you have two routers in state "medium", one of them may implement
	This by reducing power spent on features A, B, C, and D, while
	Another router would implement it by saving power on features A, B,
	E, and F.  Bringing then both routers into the "same" state "medium"
	May not be a good idea.
	
	The bottom line is that we cannot define power states in a way
	that achieves interoperability between different devices.
	Thus we don't have to fix them in our standard-to-be but rather
	should leave this open to implementers.
	
	This is close to both drafts, we are discussion, because also
	draft-claise-energy-monitoring-mib-02 already defines a table
	(pmLevelTable) for defining properties of power states.
	The only change required for solving this issue would be changing
	the index space from a fixed one (defined by an SMI enum) to a
	flexible one.  We already did so in draft-quittek-power-mib-01
	and also added there objects powerStateAveragePower and
	powerStateMaximumPower for reflecting supporting feature
	PmLevelMaxUsage in the pmLevelTable.
	
	Thanks,
	
	   Juergen

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