After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 309944 - [acpi] Wrong calculation on dual battery systems that report mA not mW
[acpi] Wrong calculation on dual battery systems that report mA not mW
Status: RESOLVED FIXED
Product: gnome-applets
Classification: Other
Component: battery
2.14.x
Other Linux
: Normal normal
: 2.12
Assigned To: gnome-applets Maintainers
gnome-applets Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-07-10 10:43 UTC by Thomas Schmidt
Modified: 2010-01-24 01:07 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14



Description Thomas Schmidt 2005-07-10 10:43:09 UTC
Distribution/Version: Debian Sarge

The calculation of the remaining battery time produces wrong results on some
systems with more than one battery, when the acpi reports the rates and
capacities on this system in mA, not in mW and both batteries have different
design voltages. The correct way to calculate the remaining time on such systems
would be to determine the current drain rate in mW and the remaining capacity in
mWh, and out of this values the remaining time.

Some details of my system:

(ACPI-Output with both batteries plugged in, without ac-power.)

chelli@w3n:~$ cat /proc/acpi/battery/BAT0/state
present:                 yes
capacity state:          ok
charging state:          discharging
present rate:            unknown
remaining capacity:      4073 mAh
present voltage:         16469 mV

chelli@w3n:~$ cat /proc/acpi/battery/BAT1/state
present:                 yes
capacity state:          ok
charging state:          discharging
present rate:            1534 mA
remaining capacity:      2371 mAh
present voltage:         11400 mV

chelli@w3n:~$ cat /proc/acpi/battery/BAT0/info
present:                 yes
design capacity:         4600 mAh
last full capacity:      4291 mAh
battery technology:      rechargeable
design voltage:          14800 mV
design capacity warning: 139 mAh
design capacity low:     23 mAh
capacity granularity 1:  52 mAh
capacity granularity 2:  2418 mAh
model number:            W3N
serial number:           00001
battery type:            LIon
OEM info:                ASUSTek

chelli@w3n:~$ cat /proc/acpi/battery/BAT1/info
present:                 yes
design capacity:         3500 mAh
last full capacity:      3643 mAh
battery technology:      rechargeable
design voltage:          11100 mV
design capacity warning: 106 mAh
design capacity low:     17 mAh
capacity granularity 1:  52 mAh
capacity granularity 2:  2418 mAh
model number:            W3N
serial number:           00001
battery type:            LIon
OEM info:                ASUSTek

As you can see, atm BAT1 (which has a design voltage of 11100 mV) is discharged
with a rate of 1534 mA (a drain rate of about17 W), remaining capacity is 94.11
Wh ((4073/1000)*(16469/1000)+(2371/1000)*(11400/1000)), this results in a
remaining battery time of 5.5 hours. Battstat would report 4,2 hours in this
situation (4073+2371)/1534.

I hope this description is enough to understand the problem. (I tested it only
on Gnome 2.8, but as far as i can see, the calculation is done in the same way
under Gnome 2.10.)
Comment 1 Danielle Madeley 2005-07-10 11:31:37 UTC
I absolutely love the consistency of /proc and the information and units it
gives us.

As an aside, it seems that the new HAL has a battery.charge_level.unit which we
can get the units from. Since the HAL backend code also doesn't seem to deal
with this.
Comment 2 Allison Karlitskaya (desrt) 2005-07-10 14:31:28 UTC
When using the HAL backend, battstat does no work on its own and relies entirely
on the HAL to do calculations for time remaining.  If this problem exists in the
HAL (which it likely does) then a bug should be filed there too.
Comment 3 Danielle Madeley 2005-07-10 14:40:02 UTC
Yeah, I have been examining the HAL code. The error will is subtly different,
more messed up, and harder for them to resolve I think. Especially as each
battery returns a battery.time_remaining but in ACPI it seems that usually only
one battery has a discharge rate. This means that we won't get a time remaining
for that battery.

Unrelated, I have realised why the HAL backend seems to take forever to update
the power status. It isn't listening to events from the kernel or ACPId, only
polling. I have emailed some people regarding this issue as the behaviour seems
broken.

Faced with these combined issues, we may want to look at disabling the HAL
backend by default in 2.12.
Comment 4 Allison Karlitskaya (desrt) 2005-07-10 14:59:24 UTC
Reporter: what's the story with one battery being at 16V and the other at 11? 
The batteries appear to have the same make and model.  Are they in fact
different batteries or is one just seriously over voltage?
Comment 5 Thomas Schmidt 2005-07-10 16:12:51 UTC
No, it is completely correct that one battery has 16V (the main one) and the
other, optional one has 11V (in the extension bay of my notebook).
Comment 6 Richard Hughes 2005-07-30 10:24:40 UTC
>Unrelated, I have realised why the HAL backend seems to take forever to update
>the power status. It isn't listening to events from the kernel or ACPId, only
>polling. I have emailed some people regarding this issue as the behaviour seems
>broken.

It does listen to /proc/acpi/event (or the acpid socket if acpid is running) and
only uses polling as a fall-back as some ACPI bios'es are really broken with
regard to sending out events.

The issues about the long delay before events changing have been fixed in hal
0.5.3 - removing the ac_adapter now reports the event *instantly* on my laptop.

Richard.
Comment 7 Danielle Madeley 2005-07-30 11:07:17 UTC
I think Ryan Lortie has highlighted existing issues in the HAL backend that need
to be examined. Specifically HAL should be sanitising units for us and doing
time calculations across multiple batteries.
Comment 8 Allison Karlitskaya (desrt) 2005-07-30 13:36:04 UTC
Davyd: I've emailed the hal list a couple of times with request for a slightly
improved interface.

It'd be extremely nice if my suggestions to the hal list got implemented in time
for their 0.5.4 release so that we could depend on them for GNOME 2.12.  This
way we could do things properly for the 2.12 release and not introduce some new
bugs with new code to use the new features.  I don't expect this to happen,
though, with such a short lead time.  I sort of dropped the ball on this one.

Either way, I think we should leave HAL enabled by default in GNOME 2.12.  It
appears to be working fairly well, and the 0.5.3 release seems to have addressed
the problems that ACPI users were having.  Certainly, if there are problems, I'd
gladly welcome bug reports and we can address them in 2.12.1.  No matter when we
do it there will be some pain and we need to deal with it eventually.

This discussion isn't really appropriate to this bug so we should probably stop
having it here :)
Comment 9 Danielle Madeley 2005-07-30 15:05:17 UTC
How well is it likely to support users with dual battery systems before our
release? This could lead to the sort of highly visible regression that makes
people think that we're simply talking bollocks. This is currently combined with
the fact we don't really know how widely tested the HAL backend currently is
(although I think Breezy is using it).

I am still currently thinking about turning it off by default in 2.12, with the
aim of making it the default in 2.14.
Comment 10 Allison Karlitskaya (desrt) 2005-07-30 16:50:37 UTC
I will fix it to work ideally as per my email to the hal-list (except for the
watts/amps stuff mentioned in this bug).  For all of the code that's not yet in
HAL, I will do the calculations for myself.
Comment 11 Richard Hughes 2005-07-30 19:48:43 UTC
> (except for the watts/amps stuff mentioned in this bug)

I've posted a patch to correct this behaviour.
http://article.gmane.org/gmane.comp.freedesktop.hal/2789

This should sort out the mAh problem in the hal backend.
Comment 12 Richard Hughes 2005-08-01 17:40:16 UTC
The mWh and mAh fixes were just committed to HAL:
http://lists.freedesktop.org/archives/hal/2005-August/002918.html
Comment 13 Allison Karlitskaya (desrt) 2005-08-01 23:04:25 UTC
GNOME 2.12 will use HAL as the default backend so this bug is fixed in 2.12.0.

Since the bug still exists in the ACPI backend code, I'm going to leave the bug
open until we commit to actually removing the code in question (maybe 2.14).
Comment 14 Danielle Madeley 2006-01-17 14:41:10 UTC
Having aquired a second battery, I've noticed a mismatch between what 'acpi' says and what battstat says.

Battstat says 6:17 remaining.

[davyd@frobisher ~]$ acpi ; cat /proc/acpi/battery/BAT?/state
     Battery 1: discharging, 94%, 05:26:53 remaining
     Battery 2: discharging, 96%, 06:31:59 remaining

present:                 yes
capacity state:          ok
charging state:          discharging
present rate:            5713 mW
remaining capacity:      31125 mWh
present voltage:         11400 mV

present:                 yes
capacity state:          ok
charging state:          discharging
present rate:            5756 mW
remaining capacity:      37605 mWh
present voltage:         11310 mV

From HAL (a little later):

PropertyModified, device=/org/freedesktop/Hal/devices/acpi_BAT2
  key=battery.remaining_time, rem=0, add=0
  value=23820
  key=battery.charge_level.rate, rem=0, add=0
  value=5605
  key=battery.charge_level.current, rem=0, add=0
  value=37087
  key=battery.reporting.rate, rem=0, add=0
  value=5605
  key=battery.reporting.current, rem=0, add=0
  value=37087

PropertyModified, device=/org/freedesktop/Hal/devices/acpi_BAT1
  key=battery.charge_level.rate, rem=0, add=0
  value=5556
  key=battery.charge_level.current, rem=0, add=0
  value=30520
  key=battery.reporting.rate, rem=0, add=0
  value=5556
  key=battery.reporting.current, rem=0, add=0
  value=30520

My intution tells me that if I have two batteries with 30000mWh of power, each drawing 5000mW I should be able to provide 12 hours of power. Have I missed something obvious?
Comment 15 Danielle Madeley 2006-01-17 14:42:39 UTC
I should point out that I am using a CVS build if 2.12 with the HAL from hoary on this machine, because I haven't updated it yet.
Comment 16 Danielle Madeley 2006-01-18 00:44:41 UTC
Frack, I know why I'm wrong. Each battery has 30000mWh and draws 5000mW, which is 6 hours/battery, however since it is 5000mW/battery the battery cancels leaving 6 hours.

Alternatively: S(capacities) / S(draws) = 60000 / 10000 => 6

I should be taken out and shot.
Comment 17 Danielle Madeley 2006-08-07 02:23:21 UTC
Can this be closed?
Comment 18 Thomas Schmidt 2006-08-10 18:50:40 UTC
Yes, as far as i can see, this bug is fixed now. (I am using Debian Etch with Gnome 2.14.2 atm.) 

(You are asking this question at a really good time, since i upgraded my laptop from Debian Sarge (Gnome 2.8) to Etch last weekend - so i really could not test if it worked before.) ;-)
Comment 19 Thomas Schmidt 2008-02-17 23:03:53 UTC
Closing this bug now, it is really fixed. (I intended to close it on 2006-08-10 allready, but it seems i did something wrong back then. (I really "like" bugzilla.)) ;-)