Design weakness in /proc/pmu ?!

Design weakness in /proc/pmu ?!

[Matthias Grimm]

Hi,

Recently I played a lot with /proc/pmu to get reliable battery states.

In the current design each battery has a value time rem. calculated out
of that battery's parameters. This calculations will fail if more than
one battery is attached to the computer as the following snapshot of a
wallstreet powerbook shows:

$ cat /proc/pmu/info
PMU driver version     : 2
PMU firmware version   : 0a
AC Power               : 0
Battery count          : 2

$ cat /proc/pmu/battery_0

flags      : 00000001
charge     : 2619
max_charge : 2639
current    : 0
voltage    : 16489
time rem.  : 0

$ cat /proc/pmu/battery_1

flags      : 00000001
charge     : 261
max_charge : 2529
current    : -1318
voltage    : 14318
time rem.  : 712

As you could see battery 0 is fully charged but the time remaining value
is calculated as zero. If you now calculate the overall time remaining
simply as sum of the time rem. of each battery you will get a wrong time
and possibly bother the user with unnessecary warnings.

I suggest to move the time rem. value out of the /proc/battery_* files
into the /proc/info file and store an overall time-remaining value
there. Because the time until power off is a quality of the whole system
mainly defined through the overall power consumption. It isn't a feature
of a single battery.

What do you think?

    Regards
     Matthias


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Design weakness in /proc/pmu ?!

[Benjamin Herrenschmidt]

>As you could see battery 0 is fully charged but the time remaining value
>is calculated as zero. If you now calculate the overall time remaining
>simply as sum of the time rem. of each battery you will get a wrong time
>and possibly bother the user with unnessecary warnings.
>
>I suggest to move the time rem. value out of the /proc/battery_* files
>into the /proc/info file and store an overall time-remaining value
>there. Because the time until power off is a quality of the whole system
>mainly defined through the overall power consumption. It isn't a feature
>of a single battery.
>
>What do you think?

It's difficult to find a suitable answer. The time remaining is
obtained directly from the PMU  on newer machines, we don't really
have the proper algorithm to calculate it on these, what
machine did you get those dumps from ? We may simply have a bug
on older machine calculation causing that 0, in which case it
has to be fixed.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Design weakness in /proc/pmu ?!

[Joseph P. Garcia]

Greetings Ben, Matthias, and others.

On Thu, 18 Apr 2002 20:31:47 +0200
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> It's difficult to find a suitable answer. The time remaining is
> obtained directly from the PMU  on newer machines, we don't really
> have the proper algorithm to calculate it on these, what
> machine did you get those dumps from ? We may simply have a bug
> on older machine calculation causing that 0, in which case it
> has to be fixed.

Each battery in the current code is handled seperately.  Each battery has
its own value for current.  A battery not in use has a value of 0, which
the time calculations handle by saying 0 time left, as if you're plugged in
and not charging, this is what would be expected.

So its not really a bug, just an implemenetation decision that mirrors the
hardware.  But I'm all for Matthias' suggestion.  The alternative is to do
what I had the gkrellm pmu plugin do. (without letting it know how to
redundantly find the time on its own just using ratios, but that assumes a
linear function)

--
Joseph P. Garcia    http://www.lycestra.com/    http://lidar.ssec.wisc.edu/
CS Undergraduate                      Student Employee - Systems Programmer
University of Wisconsin - Madison                            UW Lidar Group

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Design weakness in /proc/pmu ?!

[Matthias Grimm]

Joseph P. Garcia wrote:

> Greetings Ben, Matthias, and others.
>
> On Thu, 18 Apr 2002 20:31:47 +0200
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
>>It's difficult to find a suitable answer. The time remaining is
>>obtained directly from the PMU  on newer machines, we don't really
>>have the proper algorithm to calculate it on these, what
>>machine did you get those dumps from ? We may simply have a bug
>>on older machine calculation causing that 0, in which case it
>>has to be fixed.
>>
>
> Each battery in the current code is handled seperately.  Each battery has
> its own value for current.  A battery not in use has a value of 0, which
> the time calculations handle by saying 0 time left, as if you're plugged in
> and not charging, this is what would be expected.


Exactly that is our problem. The dumps are from a PowerBook Wallstreet
and sent to me because I did the calculation in pbbuttonsd as I have
written and ran into this problem.

On newer machines do you get a single overall system value for the time
remaining or one for each battery? Nevertheless it would be easy to
calculate _one_ valid value and store it in /proc/pmu/info.

And if the algorithm to calculate the remaining time wasn't known the
more it would be nessecary to have a reliable overall time because
applications can't find it by themselves anymore in the future.
Work-arounds weren't possible due to lack of information.


> So its not really a bug, just an implemenetation decision that mirrors the
> hardware.  But I'm all for Matthias' suggestion.  The alternative is to do
> what I had the gkrellm pmu plugin do. (without letting it know how to
> redundantly find the time on its own just using ratios, but that assumes a
> linear function)

Yes and if the number of battery types increases every application will
run into problems calulating missing values on there own. Only the
kernel could do this and as Ben already correctly said: He would keep
such a complicated piece of code in one single place.

The move would make the information in /proc/pmu more logical because
all values stored in /proc/pmu/batery_* except the remaining time were
all features of that battery and could stand for itself. The remaining
time makes only sense if you know the current power consumption of the
_whole_ computer too.

It would also be fantasic if the capacitance in mAh (mili Ampere
hours)or maybe mWh (mili Watt hours) could be added to the battery
files, but I'm not shure if you get this information from the PMU or
could calculate it out of known parameters. And at the moment this value
is only nice-to-have.

   Best Regards
     Matthias


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Design weakness in /proc/pmu ?!

[Benjamin Herrenschmidt]

>Exactly that is our problem. The dumps are from a PowerBook Wallstreet
>and sent to me because I did the calculation in pbbuttonsd as I have
>written and ran into this problem.
>
>On newer machines do you get a single overall system value for the time
>remaining or one for each battery? Nevertheless it would be easy to
>calculate _one_ valid value and store it in /proc/pmu/info.

Not that easy if we want it really valid. Note that we could still
use the other (older) PMU battery functions, maybe one of them
returns some kind of cumulated time.

>And if the algorithm to calculate the remaining time wasn't known the
>more it would be nessecary to have a reliable overall time because
>applications can't find it by themselves anymore in the future.
>Work-arounds weren't possible due to lack of information.
>
>
>> So its not really a bug, just an implemenetation decision that mirrors the
>> hardware.  But I'm all for Matthias' suggestion.  The alternative is to do
>> what I had the gkrellm pmu plugin do. (without letting it know how to
>> redundantly find the time on its own just using ratios, but that assumes a
>> linear function)
>
>Yes and if the number of battery types increases every application will
>run into problems calulating missing values on there own. Only the
>kernel could do this and as Ben already correctly said: He would keep
>such a complicated piece of code in one single place.
>
>The move would make the information in /proc/pmu more logical because
>all values stored in /proc/pmu/batery_* except the remaining time were
>all features of that battery and could stand for itself. The remaining
>time makes only sense if you know the current power consumption of the
>_whole_ computer too.
>
>It would also be fantasic if the capacitance in mAh (mili Ampere
>hours)or maybe mWh (mili Watt hours) could be added to the battery
>files, but I'm not shure if you get this information from the PMU or
>could calculate it out of known parameters. And at the moment this value
>is only nice-to-have.
>
>   Best Regards
>     Matthias
>
>
>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/