Implement IPMI POH functionality

Implement IPMI POH functionality

[Ratan Gupta]

Hi,

I would be explaining a rough idea of how we plan to go about,
This is related to https://github.com/openbmc/openbmc/issues/2979

Please share your thoughts and feedback on this proposal.

=>we were planning to add the property in the chassis interface
   which tells that since how many hours chassis was powered on.

=>This property gets updated by internal timer which wakes up after
   an hour and updates this property if chassis is powered on.

    1) Should we set the uptime to 0 if chassis state has been 
transitioned from
    PowerOn-->PowerOff

                              or

    2) Don't update this property for the chassis power off duration and 
update
    this property when the chassis state changes to PowerOn.

    What is community view on this?

    Our opinion is that we should go with option 2 as other 
implementation(AMI)
    does the same.

=> In factory reset case this property will reset to 0.

=>If BMC has been rebooted due to any reason,This property will not
   get updated for that duration and when BMC comes back,This timer
   kicks off and updates this property and it would be cumulative
   on what was the earlier value before BMC reboot.

=> Chassis object would be saved in nonvolatile storage to keep the last 
POH counter value.

=> Get functionality would be allowed,set would not be allowed from IPMI 
interface.

Regards
Ratan Gupta

Re: Implement IPMI POH functionality

[Emily Shaffer]

[-- Attachment #1: Type: text/plain, Size: 2451 bytes --]

On Mon, Mar 26, 2018 at 5:00 AM Ratan Gupta <ratagupt@linux.vnet.ibm.com>
wrote:

> Hi,
>
> I would be explaining a rough idea of how we plan to go about,
> This is related to https://github.com/openbmc/openbmc/issues/2979
>
> Please share your thoughts and feedback on this proposal.
>
> =>we were planning to add the property in the chassis interface
>    which tells that since how many hours chassis was powered on.
>
> =>This property gets updated by internal timer which wakes up after
>    an hour and updates this property if chassis is powered on.
>
>     1) Should we set the uptime to 0 if chassis state has been
> transitioned from
>     PowerOn-->PowerOff
>
>                               or
>
>     2) Don't update this property for the chassis power off duration and
> update
>     this property when the chassis state changes to PowerOn.
>
>     What is community view on this?
>

IMO, it depends on whether clients might be using this uptime to determine
whether the host is on now; or maybe whether they might need to capture the
latest uptime during some crash log that begins after the host goes down.
My gut feeling is that it's correct to set it to zero when it powers off,
and start incrementing it again starting when it powers on.  But I also
suppose it's not feasible to use uptime to determine current host state, if
the value is stored in hours, since it would be almost one full hour before
the value could report the host as "on"....

Is there a use case where someone might want to read the previous uptime,
while the host is still down?


>
>     Our opinion is that we should go with option 2 as other
> implementation(AMI)
>     does the same.
>
> => In factory reset case this property will reset to 0.
>
> =>If BMC has been rebooted due to any reason,This property will not
>    get updated for that duration and when BMC comes back,This timer
>    kicks off and updates this property and it would be cumulative
>    on what was the earlier value before BMC reboot.
>
> => Chassis object would be saved in nonvolatile storage to keep the last
> POH counter value.
>

Would it make sense to store also the real time when it was last updated,
so in case of BMC reboot like above, we could update the value to our best
guess (assuming the host did not also restart while BMC was offline)?


>
> => Get functionality would be allowed,set would not be allowed from IPMI
> interface.
>


>
> Regards
> Ratan Gupta
>
>
>

[-- Attachment #2: Type: text/html, Size: 3481 bytes --]

Re: Implement IPMI POH functionality

[Alexander Amelkin]

[-- Attachment #1.1.1: Type: text/plain, Size: 3426 bytes --]

27.03.2018 04:41, Emily Shaffer wrote:
>
>
> On Mon, Mar 26, 2018 at 5:00 AM Ratan Gupta
> <ratagupt@linux.vnet.ibm.com <mailto:ratagupt@linux.vnet.ibm.com>> wrote:
>
>     Hi,
>
>     I would be explaining a rough idea of how we plan to go about,
>     This is related to https://github.com/openbmc/openbmc/issues/2979
>
>     Please share your thoughts and feedback on this proposal.
>
>     =>we were planning to add the property in the chassis interface
>        which tells that since how many hours chassis was powered on.
>
>     =>This property gets updated by internal timer which wakes up after
>        an hour and updates this property if chassis is powered on.
>
>         1) Should we set the uptime to 0 if chassis state has been
>     transitioned from
>         PowerOn-->PowerOff
>
>                                   or
>
>         2) Don't update this property for the chassis power off
>     duration and
>     update
>         this property when the chassis state changes to PowerOn.
>
>         What is community view on this?
>
>
> IMO, it depends on whether clients might be using this uptime to
> determine whether the host is on now; or maybe whether they might need
> to capture the latest uptime during some crash log that begins after
> the host goes down.  My gut feeling is that it's correct to set it to
> zero when it powers off, and start incrementing it again starting when
> it powers on.  But I also suppose it's not feasible to use uptime to
> determine current host state, if the value is stored in hours, since
> it would be almost one full hour before the value could report the
> host as "on"....
>
> Is there a use case where someone might want to read the previous
> uptime, while the host is still down?
I believe, we must follow the IPMI specification, which clearly states
in section 1.7.28 that the POH counter is:

"to return a counter value proportional to the system operating (S0)
power-on hours"

It looks quite clear to me that this is similar to a car mileage meter.
That is, a means to identify when it's time to do some servicing and/or
track warranty.

The note in section 28.14 further backs my understanding and clarifies
the matter:

======
Note that in a power-managed system, the definition of ‘powered up’ can
be somewhat ambiguous. The definition
used here is that the power-on hours shall accumulate whenever the
system is in the operational (S0) state. An
implementation may elect to increment power-on hours in the S1 and S2
states as well.

‘Clear’ or ‘Set’ commands are not specified for this counter. This is
because the counter is most typically used for
warranty tracking or replacement purposes where changing or clearing the
counter would defeat the purpose.
======

Hence, we need to elect whether or not we want to count S1 and S2 states
(whatever they are called for POWER), but there shall be no doubt that
the value is cumulative and must not be reset to zero.

P.S. I must say that I often see how the community is trying to reinvent
IPMI without reading the specifications. I believe it is a very wrong
approach, and I implore you all to first try to find the answer in the
IPMI specification, and only when the answer can not be found, turn to
other implementations like MegaRAC or anything.

Sincerely,
Alexander.

[-- Attachment #1.1.2: Type: text/html, Size: 5139 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Implement IPMI POH functionality

[Brad Bishop]

> On Mar 28, 2018, at 8:56 AM, Alexander Amelkin <a.amelkin@yadro.com> wrote:
>> On Mon, Mar 26, 2018 at 5:00 AM Ratan Gupta <ratagupt@linux.vnet.ibm.com> wrote:
>> 
>>     2) Don't update this property for the chassis power off duration and
>> update
>>     this property when the chassis state changes to PowerOn.
> I believe, we must follow the IPMI specification, which clearly states in section 1.7.28 that the POH counter is:
> 
> "to return a counter value proportional to the system operating (S0) power-on hours"
> 
> It looks quite clear to me that this is similar to a car mileage meter. That is, a means to identify when it's time to do some servicing and/or track warranty.

Agreed.  So option #2 then Alexander?

> ‘Clear’ or ‘Set’ commands are not specified for this counter. This is because the counter is most typically used for
> warranty tracking or replacement purposes where changing or clearing the counter would defeat the purpose.

So I take this as you don’t feel a factory reset should
reset the counter, at least, certainly not by default.  Agreed?

Re: Implement IPMI POH functionality

[Alexander Amelkin]

[-- Attachment #1.1: Type: text/plain, Size: 1379 bytes --]

28.03.2018 16:38, Brad Bishop wrote:
>> On Mar 28, 2018, at 8:56 AM, Alexander Amelkin <a.amelkin@yadro.com> wrote:
>>> On Mon, Mar 26, 2018 at 5:00 AM Ratan Gupta <ratagupt@linux.vnet.ibm.com> wrote:
>>>
>>>     2) Don't update this property for the chassis power off duration and
>>> update
>>>     this property when the chassis state changes to PowerOn.
>> I believe, we must follow the IPMI specification, which clearly states in section 1.7.28 that the POH counter is:
>>
>> "to return a counter value proportional to the system operating (S0) power-on hours"
>>
>> It looks quite clear to me that this is similar to a car mileage meter. That is, a means to identify when it's time to do some servicing and/or track warranty.
> Agreed.  So option #2 then Alexander?
Yes.
>
>> ‘Clear’ or ‘Set’ commands are not specified for this counter. This is because the counter is most typically used for
>> warranty tracking or replacement purposes where changing or clearing the counter would defeat the purpose.
> So I take this as you don’t feel a factory reset should
> reset the counter, at least, certainly not by default.  Agreed?
Absolutely. We may want to have an OEM command to reset the POH counter,
but I would prefer to only have a special tool available via shell under
root account, and not let this counter be reset via IPMI or REST.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]