Subject: [eman] Do we need power state transition count and time in state?

From: john parello <[email-masked]>
Date: Thu, 07 Apr 2011 09:08:29 -0700

Hi

The requirements draft calls for an indication of the following for a state:

- time in state
- reason
- count

While working on adding multiple power state series we've found that 
this information was relevant only there was a single power state series.

Now that we have multiple series do we need this information?

I can see the usefulness of this information but the charter says we are 
to to do transitions optionally and the requirements is calling for this 
but I think it's based on a single series.

What do people think:

1) Should we keep this information?
2) If so, do we need to model this information per power state series?

Jp

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 Apr 2011 20:19:33 +0200

On Thu, Apr 07, 2011 at 09:08:29AM -0700, john parello wrote:
> I can see the usefulness of this information but the charter says we
> are to to do transitions optionally and the requirements is calling
> for this but I think it's based on a single series.
> 
> What do people think:
> 

Can you explain why multiple power state series cause a change here?

For any given point in time, is a device in just one state or in
multiple? I personally would hope only one but I am not sure...  If
not, has there been WG concensus to support devices in multiple states
of different sets concurrently?

Independent of whether there is one or multiple concurrent states,
should it not be possible to still measure the time spent in the
state(s)? Or is the issue that a device can sometimes be in one state,
at other times in two or even more? I would argue if the WG wants this
complexity, then it needs to work it out instead of removing useful
information.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 08 Apr 2011 05:04:20 +0000

Hi John

Can you please list what are the advantages and disadvantages of having
this information in multiple power state series?

Best regards,
Georgios

On 4/7/2011, "john parello" <[email-masked]> wrote:

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

---

From: Russ White <[email-masked]>
Date: Fri, 08 Apr 2011 09:51:58 -0400

> 1) Should we keep this information?

It seems like this could be inferred from traps, rather than trying to
actually store the information locally... I wonder --once you start down
the path of storing state changes, how far back do you go, etc?

I would say no, unless we have a solid reason to collect this type of
information.

Russ

-- 
[email-masked] :: CCIE :: CCDE :: <>< Grace Alone

'I suppose there are two views about everything,' said Mark.
'Eh? Two views? There are a dozen views about everything, until you know
the answer. Then theres never more than one.' -C.S. Lewis

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 8 Apr 2011 16:20:49 +0200

> I would say no, unless we have a solid reason to collect this type of

Are we talking about 3.4.1. in draft-ietf-eman-requirements-01.txt?
That text does not require to keep a history as far as I understand
it. Being able to read the current state is nice. Being able to figure
how how much time a device/component has been spent in each state
without constant polling or relying on notifications (which might not
get through) is even nicer. This is how I understand 3.4.1.

/js

---

From: Russ White <[email-masked]>
Date: Fri, 08 Apr 2011 10:23:27 -0400

> get through) is even nicer. This is how I understand 3.4.1.

When you say, "in each state," do you mean "the current state," or do
you mean, "for every previous state change," or "for n previous state
changes," or... ??

Russ

Now, we never can annihilate a penalty. We can only divert it from the
head of the man who has incurred it to the heads of others who have not
incurred it. A vast amount of "social reform" consists in just this
operation. -William Graham Sumner

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 8 Apr 2011 16:31:07 +0200

> you mean, "for every previous state change," or "for n previous state

My reading of 3.4.1. is that "each state" means each power state (not
state changes). If a box supports the five different power states,
e.g., 'full power', 'low power', 'standby', 'hibernating', 'off',
there would be five "counters" that keep track of how much time has
been spent in each of those five different power states. By example, I
would be able to read:

'full power':     24 mintues
'low power':      53 minutes
'standby':         0 minutes
'hibernating':   512 minutes
'off':         12345 minutes

Perhaps Juergen Quittek can clarify this.

/js

---

From: Russ White <[email-masked]>
Date: Fri, 08 Apr 2011 11:15:44 -0400

> 'hibernating':   512 minutes

I don't see the usefulness of this sort of information... Can someone
explain?

Russ

Extremism is a mental disorder in which a person actually believes
jumping off a fifty story building will kill you. We all know from
watching cartoons there is a high probability your shirt will be caught
on a flag pole.

---

From: Ira McDonald <[email-masked]>
Date: Fri, 8 Apr 2011 11:20:58 -0400

Hi,

FWIW - in our recent IEEE-ISTO PWG Power Model [1] and MIB [2],
we defined a REQUIRED short log of timestamped *stable* state entry
times.  So the calculation of time in state was offloaded to the remote
SNMP Manager.  Also the log can be slow-polled (although we also
defined a state transition trap).

There was a strong consensus among PWG members that this
log table was important, especially to discover abnormal patterns
of state transitions.

We made it RECOMMENDED that at least 10 entries be supported.
Here's the relevant MIB fragment:

powLogTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF PowLogEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "A table of the log entries on this Imaging System.

        Usage:  Conforming implementations SHOULD support at least 10
        entries concurrently in the powLogTable and MUST always delete
        the oldest entry first (FIFO) for memory management, i.e., the
        powLogTable always consists of a sliding window of entries with
        contiguous values of powLogIndex."
    ::= { powLog 1 }

powLogEntry OBJECT-TYPE
    SYNTAX      PowLogEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "An entry for a log entry on this Imaging System."
    INDEX     { powLogIndex }
    ::= { powLogTable 1 }

PowLogEntry ::= SEQUENCE {
        powLogIndex                     Integer32,
        powLogPowerState                PowPowerStateTC,
        powLogPowerStateMessage         SnmpAdminString,
        powLogPowerStateDateAndTime     DateAndTime,
        powLogComponentType             PowPowerComponentTypeTC,
        powLogComponentReferenceId      Integer32
    }

Cheers,
- Ira (editor of PWG Power Model/MIB)

[1] ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspower10-20110214-5106.4.pdf
[2]
ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.pdf

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:[email-masked]
Christmas through April:
  579 Park Place  Saline, MI  48176
  734-944-0094
May to Christmas:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434

---

From: "Chris Verges" <[email-masked]>
Date: Fri, 8 Apr 2011 08:34:22 -0700

Hi Russ,

While I'm not advocating for the inclusion of this feature in the
initial MIB design, such information could be useful to determine a
weighted average of power usage over time.  For example, if a device
draws a lot of power while on, but is off most of the time, then a
facilities manager can use that information to better plan for capacity
needs.

However, it does seem like EMAN is trying to do a LOT from the get-go
without publishing and finishing a base set.  I'd say this type of
meta-information probably qualifies into a second-gen of EMAN's scope,
perhaps?

Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Russ White
Sent: Friday, April 08, 2011 8:16 AM
To: john parello; [email-masked]
Subject: Re: [eman] Do we need power state transition count and time
instate?

Russ

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 8 Apr 2011 17:48:39 +0200

> I don't see the usefulness of this sort of information... Can someone

I assume people find it important to know the percentage of time a
device spends in a certain power state. Approximating this by active
polling of the current state is pretty inefficient and inaccurate
since you can miss state changes. If the device records the time spent
in each state, you get a precise breakdown of the time spend in each
power state between each poll, which means you can safely poll at a
much lower frequency.

/js

---

From: Russ White <[email-masked]>
Date: Wed, 13 Apr 2011 11:14:38 -0400

> power state between each poll, which means you can safely poll at a

It seems like this should be put into an extension, rather than in the
base spec... Or as a device specific option (given we build the branches
of information we had discussed on list before).

:-)

Russ

The bigger the government becomes, the smaller the individual becomes.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 13 Apr 2011 17:17:28 +0200

> of information we had discussed on list before).

And the reason is?

/js

---

From: Russ White <[email-masked]>
Date: Wed, 13 Apr 2011 11:19:32 -0400

>> of information we had discussed on list before).

Because this doesn't seem to be useful for all devices... And because we
should try and keep the MIB size down, with extensions, rather than
trying to bundle everything possible into the base MIB.

:-)

Russ

Belief is a wise wager. Granted that faith cannot be proved, what harm
will come to you if you gamble on its truth and it proves false? If you
gain, you gain all; if you lose, you lose nothing. Wager, then, without
hesitation, that He exists. Blaise Pascal

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 13 Apr 2011 17:52:28 +0200

> trying to bundle everything possible into the base MIB.

What about having it in the same MIB, but making it optional to implement?

    Juergen