Ira,
Thank you for the suggestions. Although I appreciate the desire to adhere to
schedule, and I appreciate the through job you are doing here, I suspect
that some work (and more participation) is necessary to come up with
suitable sets of elements applicable to the wide range of imaging products.
The following observations reflect my current thoughts on the subject, not
any hard position.
As a baseline, I understood the intent was to have the Power Management
Abstract spec be access mechanism ambivalent. That is not just SNMP and
WebServices approaches, but also Web Page and local user panel access would
follow the same model.
I consider the following to be a suitable minimum set for a lower end
machine.
1. Current power state: Pretty much the Power Monitor Group as
currently modified... three read-only elements, seems ok,. Although there
may be some pushback on date-time, at this point I think any network device
can be expected to have or be able to obtain this value.
However, if Capabilities is optional, we need to address the PowerStateWKV
question a bit further in that the actual meaning of the states in the DMTF
PowerState Values and ACPI States Table is open to interpretation w/r to a
imaging device. Perhaps a more closely defined default subset of power
states?
To muddy the question a bit, although I concurred that we concentrate on
overall unit power state, PowerSate might very well be different for
different subunits and the access may be on a Service oriented virtual
device basis. That is, a query on the state of a virtual copier, of a
printer or of a scanner. At a minimum, we should address how unit power
state can be derived from the subunit power states. Hopefully, we will
indicate how the power states of different subunits can be accessed
2. Setting Policy Values: The simplest “policy” that I believe most
devices support is setting the value of a timeout to a lower power state,
from which the device (or the subunit) can be awaken by a call to service.
Some units have several low power states, with perhaps a different timeout
from active service to each. But there should be a minimal set of predefined
timeout policies.
This is complicated in an MFD in that there well might be a subunit
differentiation both on trigger and time, and the timeout may well be
implemented via a Service. For example, potential subunit power issues are
a. Marker, with power reduction by reducing fusing heaters
b. Scanner, with lamp-off and warm-up for power and lamp-life
c. Interpreter and storage power-down for energy conservation
A simple implementation may do a separate timeout for each subunit,
triggered by some time from last use. Activity may cause a service
anticipating the use of the subunit to initiate a transition to an
operational state.
Considering your suggestions for a simple power conformance with these
requirements:
A. Power Log Group - With this minimum requirement set, I am not overly
enthused about the power log being mandatory, but requiring just two
instances should not be too much of a burden. However, since one of the
instances corresponds to the current state ( same as the Power Monitor
group), I keep wondering if there is some reasonable way to drop the Power
Monitor Group and always read the last entry in a table first (aside from
having the index always point to the most recent entry, a practice that I
believe some companies used for the PrtAlerts table).
Also, if the PowerLog is mandatory but not the PowerPolicy group, we need
either to clearly state that the LogPolicyID is always 0, or alternatively,
that there is some set of well known values for “standard” policies (of
which the latter idea seems desirable for other reasons.)
B. Capabilities - I concur with Capabilities being optional. Indeed, I
think it dangerous to allow the product-by-product redefinition of
“standard” Power State Enums. However, there would need to be a default
definition of a subset of Power States as applied to an imaging device (or
subunit). (I am curious, is it intended that there is but one message
associated with each power state? But the manufacturers can determine what
that message is?). I would say that the Power Transition Group is optional
for a lower end unit.
C. Settings – As indicated above, I think the ability to set the
timeouts (at least one, perhaps more) is necessary. But I suggest that the
existing Settings group is excessively through. I would prefer to see the
ability to identify a member of a pre-defined Power Policy set (e.g.,
timeout active to sleep, timeout active to hibernate) with an ability to
identify subunit and an ability to read and set a value (in seconds). The
Power Request group should be optional.
Thanks,
Bill Wagner
-----Original Message-----
From: Ira McDonald [mailto:blueroofmusic at gmail.com]
Sent: Monday, September 21, 2009 6:35 PM
To: William Wagner; Ira McDonald; wims at pwg.org
Subject: Re: Hints about simpler Power conformance?
Hi Bill,
[oops - deleted the duplicate line below PowerRequest,
copied from PowerPolicy - doubled the model size -:) ]
By Wednesday next week (30 September), I have to
publish some ASN.1 sketch of PWG Power Mgmt MIB,
per our project charter.
I plan to delete from the Power Model these properties:
- PowerMonitor.MonitorID (redundant, only 1 allowed)
- PowerMonitor.LastLogID (not useful, per Mike Fenelon)
- PowerRequest.RequestID (redundant, only 1 allowed)
I now suggest 3 Power conformance packages (not levels,
because they are orthogonal packages):
Status (REQUIRED)
- PowerMonitor group
(3 read-only properties)
- PowerLog group
(1 key, 4 read-only properties, minimum 2 rows)
Capabilities (OPTIONAL)
- PowerMode group (supported states)
(1 key, 5 read-only properties)
- PowerTransition group (supported transitions)
(2 keys, 1 read-only property)
Settings (OPTIONAL)
- PowerPolicy group
(1 key, 13 min-access read-only properties)
- PowerRequest group (state change)
(1 read-write property, 4 read-only properties)
Apart from simplifying (?) PowerPolicy group,
does this approach seem better to you?
I'd like to update my Model draft before our next
Monday WIMS WG, if we can come any closer
to a common vision.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
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 Mon, Sep 21, 2009 at 6:26 PM, Ira McDonald <blueroofmusic at gmail.com>
wrote:
> Hi Bill,
>> By Wednesday next week (30 September), I have to
> publish some ASN.1 sketch of PWG Power Mgmt MIB,
> per our project charter.
>> I plan to delete from the Power Model these properties:
>> - PowerMonitor.MonitorID (redundant, only 1 allowed)
> - PowerMonitor.LastLogID (not useful, per Mike Fenelon)
> - PowerRequest.RequestID (redundant, only 1 allowed)
>> I now suggest 3 Power conformance packages (not levels,
> because they are orthogonal packages):
>> Status (REQUIRED)
> - PowerMonitor group
> (3 read-only properties)
> - PowerLog group
> (1 key, 4 read-only properties, minimum 2 rows)
>> Capabilities (OPTIONAL)
> - PowerMode group (supported states)
> (1 key, 5 read-only properties)
> - PowerTransition group (supported transitions)
> (2 keys, 1 read-only property)
>> Settings (OPTIONAL)
> - PowerPolicy group
> (1 key, 13 min-access read-only properties)
> - PowerRequest group (state change)
> (1 read-write property, 4 read-only properties)
> (1 key, 13 properties, min-access read-only)
>> Apart from simplifying (?) PowerPolicy group,
> does this approach seem better to you?
>> I'd like to update my Model draft before our next
> Monday WIMS WG, if we can come any closer
> to a common vision.
>> Cheers,
> - Ira
>> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> 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
>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.