dbus-sensors:hwmontemp: additional attribute proposal

[Ed Tanous]

On Fri, Aug 7, 2020 at 11:30 AM Jason Ling <jasonling at google.com> wrote:
>
> A quick word about the original topic of this thread; we picked hwmontemp sensors where possible because we've seen performance issues for PSUSensors (could be N seconds before Sensor.Value gets updated to dbus). This has undesirable implications for PID loops..
> thought was that spreading temp sensors over into hwmontemp sensor where possible would help mitigate the performance issue until we can figure out a better long term solution.
>

Have you filed a bug, or asked on the mailing list before now?  This
is the kind of feedback the authors of that sensor need (Ideally
before you move over to another subsystem like hwmontemp).  If I
didn't see your message/bug and you did post it, I apologize, I'm not
trying to call you out.
If you have specifics, like the value of N, and the details around
what chips you're interacting with and whatever debugging you've done,
it would be helpful to put that in a bug for triage.
Keep in mind, PSUSensor by default has a 1 second scan rate.
https://github.com/openbmc/dbus-sensors/blob/41061e2c3198c0f597d4f6bb702b690a273ab45d/include/PSUSensor.hpp#L38

If it's not obeying that, clearly there's a bug to fix somewhere.

On some platforms, I have seen very high rate polling of power values
on the PSU I2c bus by other devices, and that tends to hold up
transactions for other components.  If that bus is misbehaving or
overloaded on your platform, it might have triggered a weird condition
within the PSU sensor (like the scans taking longer than the scan
rate).

If you have any more details here, it's quite possible someone will
have an idea where to look, or know exactly where the problem is.