<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Mar 26, 2018 at 5:00 AM Ratan Gupta <<a href="mailto:ratagupt@linux.vnet.ibm.com">ratagupt@linux.vnet.ibm.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I would be explaining a rough idea of how we plan to go about,<br>
This is related to <a href="https://github.com/openbmc/openbmc/issues/2979" rel="noreferrer" target="_blank">https://github.com/openbmc/openbmc/issues/2979</a><br>
<br>
Please share your thoughts and feedback on this proposal.<br>
<br>
=>we were planning to add the property in the chassis interface<br>
which tells that since how many hours chassis was powered on.<br>
<br>
=>This property gets updated by internal timer which wakes up after<br>
an hour and updates this property if chassis is powered on.<br>
<br>
1) Should we set the uptime to 0 if chassis state has been<br>
transitioned from<br>
PowerOn-->PowerOff<br>
<br>
or<br>
<br>
2) Don't update this property for the chassis power off duration and<br>
update<br>
this property when the chassis state changes to PowerOn.<br>
<br>
What is community view on this?<br></blockquote><div><br></div><div>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"....</div><div><br></div><div>Is there a use case where someone might want to read the previous uptime, while the host is still down?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Our opinion is that we should go with option 2 as other<br>
implementation(AMI)<br>
does the same.<br>
<br>
=> In factory reset case this property will reset to 0.<br>
<br>
=>If BMC has been rebooted due to any reason,This property will not<br>
get updated for that duration and when BMC comes back,This timer<br>
kicks off and updates this property and it would be cumulative<br>
on what was the earlier value before BMC reboot.<br>
<br>
=> Chassis object would be saved in nonvolatile storage to keep the last<br>
POH counter value.<br></blockquote><div><br></div><div>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)?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
=> Get functionality would be allowed,set would not be allowed from IPMI<br>
interface.<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards<br>
Ratan Gupta<br>
<br>
<br>
</blockquote></div></div>