phosphor-hwmon bottleneck potential
patrick at stwcx.xyz
Sat May 6 06:13:28 AEST 2017
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 at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: Digital signature
More information about the openbmc