{"id":2507,"date":"2010-05-27T20:37:02","date_gmt":"2010-05-28T03:37:02","guid":{"rendered":"http:\/\/multimedia.cx\/eggs\/?p=2507"},"modified":"2020-07-25T22:10:05","modified_gmt":"2020-07-26T05:10:05","slug":"monster-battery-power-revisited","status":"publish","type":"post","link":"https:\/\/multimedia.cx\/eggs\/monster-battery-power-revisited\/","title":{"rendered":"Monster Battery Power Revisited"},"content":{"rendered":"

So I have this new fat netbook battery and I performed an experiment<\/a> to determine how long it really lasts. In my last post on the matter, it was suggested that I should rely on the information that gnome-power-manager<\/a> is giving me. However, I have rarely seen GPM report more than about 2 hours of charge; even on a full battery, it only reports 3h25m when I profiled it as lasting over 5 hours in my typical use. So I started digging to understand how GPM gets its numbers and determine if, perhaps, it’s not getting accurate data from the system.<\/p>\n

I started poking around \/proc for the data I wanted. You can learn a lot in \/proc as long as you know the right question to ask. I had to remember what the power subsystem is called — ACPI — and this led me to \/proc\/acpi\/battery\/BAT0\/state which has data such as:<\/p>\n

\r\npresent:                 yes\r\ncapacity state:          ok\r\ncharging state:          charged\r\npresent rate:            unknown\r\nremaining capacity:      100 mAh\r\npresent voltage:         8326 mV\r\n<\/pre>\n
“Remaining capacity” rated in mAh is a little odd; I would later determine that this should actually be expressed as a percentage (i.e., 100% charge at the time of this reading). Examining the GPM source code, it seems to determine as a function of the current CPU load (queried via \/proc\/stat) and the battery state queried via a facility called devicekit. I couldn’t immediately find any source code to the latter but I was able to install a utility called ‘devkit-power’. Mostly, it appears to rehash data already found in the above \/proc file.<\/p>\n
Curiously, the file \/proc\/acpi\/battery\/BAT0\/info, which displays essential information about the battery, reports the design capacity of my battery as only 4400 mAh which is true for the original battery; the new monster battery is supposed to be 10400 mAh. I can imagine that all of these data points could be conspiring to under-report my remaining battery life.<\/p>\n
Science project:<\/strong> Repeat the previous power-related science project<\/a> but also parse and track the remaining capacity and present voltage fields from the battery state proc file.<\/p>\n
Let’s skip straight to the results (which are consistent with my last set of results in terms of longevity):<\/p>\n

\n
\n<\/center><\/p>\n
So there is definitely something strange going on with the reporting– the 4400 mAh battery reports discharge at a linear rate while the 10400 mAh battery reports precipitous dropoff after 60%. <\/p>\n
Another curious item is that my script broke at first when there was 20% power remaining which, as you can imagine, is a really annoying time to discover such a bug. At that point, the “time to empty” reported by devkit-power jumped from 0 seconds to 20 hours (the first state change observed for that field).<\/p>\n
Here’s my script, this time elevated from Bash script to Python. It requires xdotool<\/a> and devkit-power to be installed (both should be available in the package manager for a distro).
\n<\/p>\n