Re: phosphor-hwmon bottleneck potential

[Patrick Williams <patrick@stwcx.xyz>]

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

On Fri, May 05, 2017 at 11:52:15AM -0700, Rick Altherr wrote:
> On Fri, May 5, 2017 at 11:37 AM, Nancy Yuen <yuenn@google.com> wrote:
> > 2. So putting the onus on each application to implement timestamps is
> > better design than having timestamps recorded by a central source, the
> > source that actually is reading from the driver?

> Re #2: timestamps lose value as they shift away from the time of the actual
> measurement.  Ideally, the hardware would timestamp the sample, hwmon would
> preserve and provide that timestamp to the userspace.

I'm not seeing the utility, specifically in the context of a fan control
algorithm, for a timestamp to know when the reading occurred having been
described.  I do see a need for it in the context of a "repository of
historical sensor values" such as what we will need to implement the
DCMI interfaces for IPMI.

I don't have any problem with a timestamp being added to the
dbus-objects being presented by phosphor-hwmon.  We do have Timestamp
property on xyz.openbmc_project.Logging.Entry already.  I would suggest
we make a xyz.openbmc_project.Common.Timestamp interface instead and
transition the logging entry server to including it.  The reason being
that I've recently had some questions about the date-time format we are
presenting across REST (ms since 1970 as uint64) as being difficult for
humans; having a Common.Timestamp interface makes it much easier for the
REST server (and later Redfish) to identify "things representing time
that should be converted to date-time format".

There is an issue with having two properties in a single dbus object
being changed at the same time and generating a single signal for it.
The org.freedesktop.DBus.Properties.PropertiesChanged signal only allows
a single interface, which might be an argument against what I wrote in
the previous paragraph.  Also, the sdbusplus-generated bindings do not
currently have a mechanism to indicate multiple properties changing as a
transaction even on a single interface.

If we do add a timestamp we need to be clear on what the expected
behavior of it is.  As we are seeing with this issue there can be some
time between sysfs read-start and read-end.  Also, if we are reading an
external device, like the fan controller on Witherspoon, the value
obtained isn't an instantaneous fan speed but an average over some
hardware-defined interval.  So I think we would need some language such
that "time immediately after sysfs read-end" is a valid representation.

-- 
Patrick Williams

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]