Hi Bill,
Replies inline below.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
email: blueroofmusic at gmail.com
winter:
579 Park Place Saline, MI 48176
734-944-0094
summer:
PO Box 221 Grand Marais, MI 49839
906-494-2434
On Fri, Jan 22, 2010 at 2:55 PM, William Wagner <wamwagner at comcast.net> wrote:
> Hi Ira,
>>>> At the last concall we had discussed making a point of the distinction
> between Power State and Operational State. Certainly, power consumption will
> be a function of both Power State and Operational State. And there will be
> some restriction on allowable Operational State depending upon power state.
> It may not be possible to define a clear or device-independent relationship
> between the two types of states.
>
<ira>
Per ACPI and CIM Schema, the relationship between Operational States
and Power States is implementation-defined - the devices, CPU platforms,
and operating systems already exist - practically speaking, we can't now
constrain them.
</ira>
>>> As I reviewed the power states in the MIB (PowPowerStateTC), some questions
> come up on what states are reportable and what are selectable, as well as
> what may be considered not power states (although I understand that these
> states are derived from other standards)
>>>> 1. I was assuming that any of the listed states could be a response, but
> that only what have been elsewhere identified as “Stable” states could be
> used in a request. This followed from an understanding that the non-stable
> states were transition power states, and one would typically request the
> desired end state, not a transition state. But one may want to request how
> the desired end state is reached, so that requesting “off”,“offGraceful”,
> “offHard”, or “offHardGraceful” would reasonable be desirable different
> requests. Is it your understanding that any of the listed power states
> could be used in a request (although I would wonder about resetNMI) ?
>
<ira>
With the exception of the device interrupt power states (i.e., leading edges
of transitions to some Stable power state), *all* of the power states may be
included in a request. The Stable power states are the end power states of
transitions (and also directly requestable themselves, of course).
On various embedded systems, I've seen implementations that will accept
any of the device interrupt power states as well (they simulate them).
</ira>
> 2. If this is so, then can the reset states be requested? One may
> consider that the various resets are operational rather than power
> transition states. That is, although there may be an effect upon power
> consumption by a reset as there is when going from Idle to Busy, a reset
> would typically occur for operational rather than for power purposes. Is the
> Power MIB to also expand the capability for what are really operational
> resets?
>
<ira>
Yes - the power resets are *meant* for use in Power State requests (just
like in Printer MIB). They *result* in a change in Operational State as well.
</ira>
> 3. If, as it appears, the Power states other that the six “stable”
> states are transitory but not transition states, what should be reported
> when the device is in transition between two stable states? Or are we not
> concerned with what would normally be a relatively short duration transition
> state?
>
<ira>
My opinion - we're not concerned.
I think it's not interesting that a hardware interrupt occurred (and also it's
hard to log), but the resulting stable Power State is interesting.
On the other hand, logging 'offGraceful' (orderly shutdown) is probably
interesting.
Again - it's a implementation-defined.
Some vendors have very detailed prtAlertTable entries - others have
arguably too sparse prtAlertTable entries - it's the customer's problem.
</ira>
> 4. The offHard state is defined as “mechanical unplug”, which suggests
> that it cannot be either reported nor requested, rendering it useless and
> eliminating the availability of a not-powered state (since “off” is “flea
> power”) . I expect that offHard really means unpowered, whether the
> disconnect is by pulling a plug, opening relay contacts or shutting off a
> Triac. If so suggest that unpowered is preferable to mechanical unplug.
> Similarly, associating the “off” state with “flea power” is not very
> informative, particularly for non-English speakers. Is the implication that
> enough of the unit powered so that a remote command (from some source) can
> be accepted? (one would assume that, if the agent is sufficiently powered to
> response to a status request, it is sufficiently powered to accept a
> state-change request).
>
<ira>
You meant 'offSoft' rather than 'off' has flea power (we clarified
that 'off' is a
Power Mode, *not* a Power State - the Model and MIB reflect this).
For a Subunit, 'offHard' (unplugged) is certainly a possible and reportable
power state - that's why we have a single Power Log for the whole device,
stored on the System object.
The mechanical unplug terminology is taken from CIM which quotes ACPI.
We can perhaps clarify. But the essence of 'offHard' is that absolutely *no*
power is consumed by the referenced System or Subunit.
</ira>
>>> Again, I understand that these states are inherited and should be supported
> for consistency. However, I think that more explanation of how they apply to
> hardcopy equipment may be appropriate to encourage consistency in
> implementation.
>
<ira>
Again - the MFDs and printers already exist and have chosen a wide variety
of implementations of Power States - we can't constrain them to 'fix' their
implementations - and in the frequent case that they outsource motherboards
and realtime/embedded operating systems, even the vendors can't easily
'fix' their implementations.
As Pete Zehler would say, what's really important is that a device always
reports the same Operational State and Power State at a given instant
via *all* the available interfaces - and that they only report, for example,
'offSoft' when that is the *accurate* Power State.
</ira>
>>> Thanks,
>>>> Bill Wagner
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.