Message-ID: <20220714133800.GA3916254@roeck-us.net>
Date:   Thu, 14 Jul 2022 06:38:00 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     "Kallas, Pawel" <pawel.kallas@...el.com>
Cc:     jdelvare@...e.com, corbet@....net, linux-hwmon@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
        iwona.winiarska@...el.com
Subject: Re: [PATCH 0/3] hwmon: (pmbus) add power from energy readings

On Thu, Jul 07, 2022 at 06:00:45PM +0200, Kallas, Pawel wrote:
> 
> On 07-Jul-22 4:09 PM, Guenter Roeck wrote:
> > On Thu, Jul 07, 2022 at 04:01:54PM +0200, Kallas, Pawel wrote:
> > > On 06-Jul-22 3:17 PM, Guenter Roeck wrote:
> > > > On Wed, Jul 06, 2022 at 12:40:21PM +0200, Kallas, Pawel wrote:
> > > > > Add support for reading EIN or EOUT registers and expose power calculated
> > > > > from energy. This is more accurate than PIN and POUT power readings.
> > > > > Readings are exposed in new hwmon files power1_average and power2_average.
> > > > > Also add support for QUERY command that is needed to check availability
> > > > > of EIN and EOUT reads and its data format. Only direct data format is
> > > > > supported due to lack of test devices supporting other formats.
> > > > > 
> > > > I don't think this is a good idea. EIN/EOUT report energy consumption,
> > > > not power.
> > > According to PMBus-Specification-Rev-1-3-1-Part-II-20150313 "READ_EIN and
> > > READ_EOUT commands provide information that can be used to calculate power
> > > consumption". That is accumulator summing instantaneous input power
> > > expressed in "watt-samples" and counter indicating number of samples.
> > > The only reasonable thing that can be done with those values is calculating
> > > power.
> > Yes, but that is not the responsibility of the kernel. Just like we don't add
> > up power measurements to calculate energy, we don't take energy measurements
> > and calculate power consumption. Similar, we don't take voltage and current
> > measurements and report power consumption from it either.
> > 
> > > > The "average" attributes as implemented don't really report
> > > > a reliable number since the averaging period is not defined.
> > > Agree, it is calculating average power since last read, which could be
> > > incorrect with multiple consumers. However, this is the only possibility
> > > without adding some timer logic.
> > Another reason for doing it in userspace. Read energy every N seconds, and use
> > the difference to calculate average power consumption average over that time
> > period.
> We cannot "read energy". Raw value from READ_EIN and READ_EOUT is not
> energy.

Sure, it is an accumulation of power reading samples over time. as such,
it doesn't really even report a power average. Either case, any value
derived from it is all but worthless unless a well defined time interval
is available.  Unfortunately, such a time interval would require a kernel
timer, which would, at least in low power situations, have impact on the
power readings and is thus unacceptable. Maybe that is why later PMBus
specification introduced explicit READ_KWH_IN and READ_KWH_OUT commands.

> > > > Also, kernel
> > > > drivers should not make up such numbers. I don't mind adding energy
> > > > attribute support, but that should be reported as what it is, energy.
> > > > What userspace does with it would then be a userspace concern; it can
> > > > calculate all kinds of averages from it as much as it wants.
> > > Returning direct value of read registers would also work for our use case,
> > > but it is not in line with sysfs interface.
> > I did not suggest that. Just use the "energyX_in" attributes.
> Expressing raw value from READ_EIN or READ_EOUT is not in line with
> sysfs interface, because "energyX_in" should have microJoules as unit.
> Those commands have very specific format that is not actually energy.
> Since the only sensible use case for those raw values is calculating power
> we figured it would be better (and more accurate) to do it in kernel.
> Also, if we just express raw value, the user would have to know data format
> of the values for the device and know register format to decode the data.

A joule is one watt-second, and the registers accumulate power samples over
a period of time. Sure, dividing the reported values by the time interval
results in the average power consumption over that time interval. Just like
multiplying the average power consumption with the time interval results in
the energy consumption over that timer interval. If we say we can't
determine the energy because the accumulated values are just snapshots in
time, we just as well can't trust the average power calculated from it.

Anyway, I don't really see an acceptable solution. Reporting the average
power would require a periodic function running every second or so which
would at least potentially falsify the reported values, and if you say that
reporting the energy (which might still require a timer function, but less
frequently) isn't feasible I take you by your word.

Guenter

> > 
> > Thanks,
> > Guenter
> > 
> > > > Also, new attributes should not depend on query command support.
> > > > I don't mind adding support for that, but it would have to be independent
> > > > of energy attribute support.
> > > > 
> > > > Thanks,
> > > > Guenter
> > > > 
> > > > > Kallas, Pawel (3):
> > > > >     hwmon: (pmbus) add support for QUERY command
> > > > >     hwmon: (pmbus) refactor sensor initialization
> > > > >     hwmon: (pmbus) add EIN and EOUT readings
> > > > > 
> > > > >    Documentation/hwmon/pmbus-core.rst |   7 +
> > > > >    drivers/hwmon/pmbus/pmbus.c        |  20 +++
> > > > >    drivers/hwmon/pmbus/pmbus.h        |  19 +++
> > > > >    drivers/hwmon/pmbus/pmbus_core.c   | 261 +++++++++++++++++++++++++++--
> > > > >    4 files changed, 291 insertions(+), 16 deletions(-)
> > > > > 
> > > > > 
> > > > > base-commit: 7c1de25c06f31b04744beae891baf147af9ba0cb

Powered by blists - more mailing lists