Showing posts with label battery. Show all posts
Showing posts with label battery. Show all posts

Friday, 16 November 2012

Non linear characteristics in a draining battery on the Nexus 7

Measuring power consumption on low power devices really is not as simple as running tools such as PowerTop and then assuming the data is trustworthy.  I shall explain why.

With Ubuntu on the Nexus 7, the battery driver originally provided battery capacity in terms of percentage full, which lacked precision to make any sane power consumption estimates.   We tweaked the battery driver so that we could get battery capacity in terms of uWh from the bq27541 battery fuel gauge.  From this, one can measure the change in capacity over time and estimate the power consumed by the device.

For the Ubuntu 12.04 Precise release I wrote the lightweight power measurement tool "powerstat" to try to determine power consumption using the change in battery capacity.  Powerstat can gather changes in the battery capacity level and by using a simple sliding window on the samples it gives an estimate on the power being consumed over time.  With laptops that consume a lot of power this provides a reasonable rough estimate of power consumption.

The tweak to the Nexus 7 battery driver allows powerstat to work on the Nexus 7 running Ubuntu.  So how trustworthy is the battery data from the battery fuel gauge?  Is the data reliable if we repeat the test under the same conditions?  Do we get consistent readings over time?

For my first set of tests, I fully charged the Nexus 7 and then fully loaded the 4 CPUs with busy loops and then ran multiple powerstat tests; powerstat gathers samples over 8 minutes and estimates power consumption. It also calculates the standard deviation from these samples to give us some idea of the variability of the battery power measurements.    For each powerstat test I logged the battery voltage level, the % battery capacity (normalized to a range of 0..1 to make it easier to plot), the estimated power consumption (with its standard deviation) and then plotted the results:
With this test the machine is in a steady state, we are not changing the load on the CPUs, so one should expect a steady power measurement.  But as one can see, the battery gauge informs us that the voltage is dropping over time (from ~4V down to ~3.25V) and the estimated power also varies from 4.6W down to 3.3W.  So, clearly, the power estimate will depend on the level of charge in the battery.

I also measured an idle machine:

Again, voltage drops over time and estimated power drops too.  More interesting is that the estimated power measurement is not particularly smooth over time as shown by the plot of the standard deviation too.   We can therefore conclude that a lightly loaded machine has a lot of variability in the estimated power consumption data and this means we cannot realistically measure subtle power optimization tweaks made to the software as there is just too much variability in the data.

I re-ran the idle test over several days, running from the same fully charged state to a completely empty battery, and compared runs.  I got variability in the duration of the test (+/- 5%). Also, comparing estimated power consumption at the 100%, 75%, 50% and 25% battery capacity points also shows a lot of variability. This means one cannot get accurate and repeatable power estimations even when the battery is charged at specific capacities.

So next time somebody tells you that the latest changes made their low power device suck more (or less!) power than the previous release and their findings are based on data derived from battery fuel gauge, take it with a pinch of salt.  

The only reliable way to measure instantaneous power consumption is using specialised precision equipment that has been accurately calibrated.

Saturday, 3 March 2012

Dell 1525 battery not charging

My wife's Dell 1525 Ubuntu laptop starting having battery problems last year and eventually we ended up with a totally dead Li-ion battery.   Fortunately I was able to acquire a clone replacement for about £25 which charged fine and worked for a week before becoming totally drained.

According to some users, this happens because the charging circuitry has died, which was a little alarming since the machine was way out of warranty.  So I had a machine that runs fine on AC power, but the battery won't charge.   So I slept on the problem and this morning I thought I'd try another spare Dell AC adapter just to factor out the AC power supply.  To my surprise the battery started charging, so I had to conclude the problem is simply due to a broken AC power supply.

So if the AC power supply is not charging, perhaps the original battery wasn't dead after all.  I plugged in the old battery, gave it an hour to charge but found it really was dead and useless.

I've compared the characteristics of the working power supply against the broken one with a multimeter and I cannot see any difference, which strikes me a little curious.   If anyone has any ideas why one works and other other doesn't please let me know!

UPDATE

After a bit of research I found a relevant article at laptop-junction.com [1] that describes the AC adapter battery charging issue.   So it seems that this is a common issue [2]  for a bunch of AC adapters and the author suggests a possible design issue [3].

References:

[1] http://www.laptop-junction.com/toast/content/battery-not-charging
[2] http://www.laptop-junction.com/toast/content/dell-ac-power-adapter-not-recognized
[3] http://www.laptop-junction.com/toast/content/dell-ac-power-adapter-id-chip-died

Tuesday, 13 December 2011

Improving Battery Life in Ubuntu Precise 12.04 LTS

Part of my focus this cycle is to see where we can make power saving improvements for Ubuntu Precise 12.04 LTS. There has been a lot of anecdotal evidence of specific machines or power saving features behaving poorly over the past few cycles.   So, armed with a 6.5 digit precision multimeter from Fluke I've been measuring the power consumption on various laptops in different test scenarios to try and answer some outstanding questions:

* Is it safe to enable Matthew Garrett's PCIe ASPM fix?
* Are the power savings suggested by PowerTop useful and can we reliably enabled any of these in pm-utils?
* How accurate are the ACPI battery readings to estimate power consumption?
* Do the existing pm-utils power.d scripts still make sense?
* Which is better for power saving: i386, i386-pae or amd64?
* How much power does the laptop backlight really use?
* Does halving the mouse input rate really save that much more power?
* Should we re-enable Aggressive Link Power Management (ALPM)?
* Are there any misbehaving applications that are consuming too much power?
* What are the root causes of HDD wake-ups
* Which applications and daemons are creating unnecessary wake events?
* How much does the MSR_IA32_ENERGY_PERF_BIAS save us?

..and many more besides!

From some of the analysis and "crowd sourcing" tests it is clear that the PCIe ASPM fix works well, so we've already incorporated that into Precise.

Aggressive Link Power Management (ALPM) is a mechanism where a SATA AHCI controller can put the SATA link that connects to the disk into a very low power mode during periods of zero I/O activity and into an active power state when work needs to be done. Tests show that this can save around 0.5-1.5 Watts of power on a typical system. However, it has been known in the past to not work on some devices, so I've put a call for testing of ALPM out to the community so we can get a better understanding of the power savings vs reliability.

Some of the PowerTop analysis has shown we can save another 1-2 Watts of power by putting USB and PCI controllers of devices like Webcams, SD card controllers, Wireless, Ethernet and Bluetooth  into a lower power state.  Again, we would like to understand the range of power savings across a large set of hardware and to see how reliable this is, so another crowd sourced call for testing has been also set up.

So, if you want to contribute to the testing, please visit the above links and spend just a few tens of minutes to see we can extend the battery life of your laptop or netbook.  And periodically visit https://wiki.ubuntu.com/Kernel/PowerManagement to see if there any new tests you can participate in.

[UPDATE]

I've written some brief notes on power saving tweaks and also some simple recommendations for application developers to follow too.

The thread continues here (part 2)

Saturday, 11 July 2009

Power Consumption During Hibernation

When a Linux laptop or netbook is hibernated you would assume that it's not drawing any power from the battery and so it can be left hibernated for months. Well, that's not strictly true!

Firstly, one has to consider the fact that laptops and netbooks have an embedded controller inside that consume a slight amount of power. Also, for some reason, some machines may flash a LED periodically to show that the machine is hibernated, this too draws a very small amount of power.

One can measure the amount of power being used during hibernation using the following recipe:

First, we need to measure the power used to just hibernate:

1. firstly charge up your laptop battery and then unplug the power plug,
2. measure the battery capacity. I have a simple script to do this,
3. hibernate the machine and then immediately resume it,
4. measure the battery again,
5. subtract the measurement in step 2 from the measurement in step 4. This is the amount of power used to do a hibernate cycle (e.g. power used to write memory to disc, and the reverse on wake up).

Next, we need to measure the amount of power used for a LONG hibernate:

6. measure the battery capacity again.
7. hibernate the machine for more than 30 minutes, e.g. for 1 hour is good, and then wake it up.
8. measure the battery once more. Subtract the figure from step 6 away, and also the figure derived in step 5 away and you then have the amount of power consumed just to do the long hibernate.

I've hacked up a script to do this automatically - it's still work in progress through, it may not work on some machines because the ACPI alarm may not be 100% reliable.

You may be surprised how much power is being used to do nothing!

So what's consuming all this power? Well, some of the power loss could be due to battery leakage - older batteries seem to suffer more than newer ones, but this cannot be the full story. From my tests the power consumption can be due to:

1. Battery leakage. Varies depending on battery age and type.
2. The Embedded Controller just being busy and flashing LEDs etc.
3. Devices not being fully turned off, e.g. Wifi, Bluetooth etc.
4. Others - probably poor laptop design(?)

Hopefully drivers will improve to fix issue 3 and Intel power management in general should improve over time too. Indentifying the bad drivers is the next step in my quest, but don't hold ones breath - there is a lot of code and the information on a lot of hardware is closed, so figuring out how to make it more power efficient is not straight forward!

I also believe the ACPI wake alarm can also suck a little power. This can be used to wake the machine up at some predetermined time in the future, for example MythTV boxes used this feature to wake up a PC to start recording TV. Turning off the alarm probably saves a little amount of power, one trick is to program it to trigger in the next second or so, and then hibernate the machine.

Any other ideas on exactly where all that power is going would be appreciated!

Meanwhile, just don't assume hibernation is totally power friendly :-)