GNOME Bugzilla – Bug 309944
[acpi] Wrong calculation on dual battery systems that report mA not mW
Last modified: 2010-01-24 01:07:42 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.)
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.
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.
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.
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?
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).
>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.
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.
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 :)
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.
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.
> (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.
The mWh and mAh fixes were just committed to HAL: http://lists.freedesktop.org/archives/hal/2005-August/002918.html
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).
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?
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.
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.
Can this be closed?
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.) ;-)
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.)) ;-)