Hi Bill,
Yes - the powLogTable is strictly ordered by powLogIndex (with
increasing corresponding values of powLogDateAndTime).
Quoting description of powLogIndex directly from the Power MIB:
Usage: Values of this object MUST monotonically increase over
time and MUST NOT reset in the lifetime of this Imaging System.
Usage: Values of this object MUST be persistent across system
reboots.
Other tables in Power MIB don't have strict monotonic indices and
can have discontinuites after a major system reconfiguration, but
NEVER powLogTable.
MORE strict than prtAlertIndex and prtAlertTime in Printer MIB - which
merely recommends persistence and doesn't disallow reuse of a value
of prtAlertIndex after aging/reboots.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing 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 Sun, Dec 6, 2009 at 9:57 PM, William Wagner <wamwagner at comcast.net> wrote:
> Hi Ira,
>> Sorry, I am still confused by last part of your statement "Deleted
> unnecessary primary index of powMonitorIndex from powLogTable (which applies
> only to System object)"
>> The MIB descriptions indicate that subunit power states are also included in
> the log. I would assume that having a single monotonically increasing index
> means that all power state-monitored components have their state transitions
> sequentially entered into the same columns of the table, more or less in the
> sequence that they occurred.
>> If that is not it, perhaps its best to address this at the meeting. I would
> not assume that much of the group is aware of the Projector Display MIB or
> the considerations that went into it, so you may have to restate the
> reasoning.
>> Thanks,
>> Bill Wagner
>> -----Original Message-----
> From: Ira McDonald [mailto:blueroofmusic at gmail.com]
> Sent: Sunday, December 06, 2009 6:27 PM
> To: William Wagner; Ira McDonald
> Cc: wims at pwg.org> Subject: Re: [WIMS] PWG Imaging System Power MIB (4 Dec 2009)
>> Hi Bill,
>> No - the log of an subunit object might become inaccessible.
>> Having to read across all of the Subunit objects (especially in
> XML interfaces) would be onerous. This was the wisdom
> from the Projector Display MIB effort.
>> Anyway, with Rick's guidance we designed a FLAT log that
> intersperses all power transitions on System or any Subunit.
> That's what's been in Power Model for quite awhile.
>> It was a BUG in Power MIB that I included powMonitorIndex
> for powLogTable.
>> powLogComponent[Type / ReferenceId] fields in each row
> identify each logged component (see Descriptions in MIB).
>> Cheers,
> - Ira
>> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing 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 Sun, Dec 6, 2009 at 6:18 PM, William Wagner <wamwagner at comcast.net>
> wrote:
>> Ira,
>>>> Although I like simplification, I am unsure about "Deleted unnecessary
>> primary index of powMonitorIndex from powLogTable (which applies only to
>> System object), keeping only needs powLogIndex, per PWG Power Management
>> Model" Are you saying that only System power states are logged? That is
>> unclear and perhaps unreasonable. If monitored subunit states are also
>> logged, having them organized by component maybe useful (e.g., a manager
> may
>> only be interested in System power states.)
>>>> Thanks,
>>>> Bill Wagner
>>>> -----Original Message-----
>> From: wims-bounces at pwg.org [mailto:wims-bounces at pwg.org] On Behalf Of Ira
>> McDonald
>> Sent: Friday, December 04, 2009 3:59 PM
>> To: wims at pwg.org; Ira McDonald
>> Subject: [WIMS] PWG Imaging System Power MIB (4 Dec 2009)
>>>> Hi,
>>>> [For review next Tuesday 8 December during PWG F2F in Austin]
>>>> I've just posted an Interim draft of the PWG Imaging System Power MIB:
>>>>ftp://ftp.pwg.org/pub/pwg/wims/wd/wd-wimspowermib10-20091204.mib>> - full ASN.1 source with compliance statements, defaults, references,
> etc.
>>>>ftp://ftp.pwg.org/pub/pwg/wims/wd/wd-wimspowermib10-20091204.pdf / doc
>> - full MS Word document with all sections completed
>>>> Cheers,
>> - Ira
>>>> --------------------------------------------------
>> Changes made to create 4 December 2009 version (Interim Draft)
>>>> Editorial - Changed document status to Interim
>>>> Editorial - First MS Word draft
>>>> Technical - Added usage clauses to index objects requiring
>> persistence across system reboots, except for major system
>> reconfigurations, per Bill Wagner
>>>> Editorial - Renamed pow[Monitor/Log]ComponentId to
>> pow[Monitor/Log]ComponentReferenceId, per WIMS WG
>> discussion
>>>> Technical - Deleted unnecessary primary index of
>> powMonitorIndex from powLogTable (which applies only to
>> System object), keeping only needs powLogIndex, per PWG
>> Power Management Model
>>>> Technical - Added usage clause to powLogIndex to require
>> monotonically increasing and MUST NOT reset during lifetime
>> of Imaging System, for reliability
>>>> Editorial - Renamed powSupportPowerUsageWatts
>> (ambiguous) to powSupportPowerNominalWatts, per WIMS
>> WG discussion
>>>> --------------------------------------------------
>>>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>>> _______________________________________________
>> wims mailing list
>>wims at pwg.org>>https://www.pwg.org/mailman/listinfo/wims>>>>>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>>> _______________________________________________
>> wims mailing list
>>wims at pwg.org>>https://www.pwg.org/mailman/listinfo/wims>>>>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.