Thursday, December 09, 2010

Prolonging the battery life on your laptop/netbook running Ubuntu

mdz pointed me to Idea 24782 over at Ubuntu Brainstorm that urges the Ubuntu community to increase focus on making Ubuntu run longer on devices with batteries. I support the idea wholeheartedly. Since the advent of laptops and netbooks, users have wanted to stretch the battery to last that extra 15 minutes it'll require for them to finish up their email or their documents.


In fact, the most popular idea ever on Brainstorm is about fixing suspend and hibernate. Unfortunately, it ended up becoming a whirlpool of several different ideas, albeit with a common theme - making the battery last longer.


There are several things that can be done to make the battery on a mobile device last longer - some under user control, others under OS/firmware control and some others dependent on HW capabilities.


I am going to attempt to summarize the various use profiles and what Ubuntu does (or can do) to prolong battery life in those profiles. Power management, when done right, should not require the user to make several (difficult) choices. It should just work - providing a good balance of performance and battery life.


Battery Maintenance


Let's start with the most basic fact of mobile devices - most have batteries made with Lithium technology (LI-ON mostly). These have a typical life of 2-3 years because then have a limited number of charge/discharge cycles (between 300-1000, check your manual)[1][2]. Keeping your mobile battery in good shape will make it last longer. Hence,

  1. Don't keep the mobile device plugged into mains all the time; letting the battery discharge is important for it's longevity. If you must do leave it in all the time, consider removing the battery (at the risk of losing your work on power failure).
  2. Don't expose the battery to high temperatures. The cooler your working environment (including your laptop chassis), the longer your battery will keep its charge.

Toward this end, solution 3 is a very good suggestion. gnome-power-manager, for instance, could tell us when to unplug the power cord.


When not using the device for long periods (greater than 4 hours)


Turning off the device when not in use for long periods is an obvious way to improve your battery life. With Ubuntu booting in under 30 seconds on most machines now and ~15 seconds on machines with SSDs[3] this is a good option.


Using suspend (to RAM) here continues to drain the battery (about 25% per day on most machines I've had). That means 4 days of suspend just reduced the remaining charge/discharge cycles by one.


Hibernate (suspend to disk) is a better option than suspend here since the state will be saved to disk and the machine turned off completely. But in practice, with the current implementation of hibernate in Linux, we take almost as long to restore the disk image on resume as a fresh boot up. So hibernate really isn't my preference. If hibernate could be made a lot faster, it could become more attractive than a fresh boot.


When not using the device for short periods (under 4 hours)


This is a very common case when you're using your device on the go - at the airport or a conference or a coffee-shop or a meeting. You use the mobile device for a while, then close the lid to move to a new location or to concentrate on the discussion, etc.


You do one of two things: let the device idle with the lid open or close the lid and let the device suspend. We need to ensure that both these cases draw the least possible power. This requires co-operation from the applications and Linux drivers.


Idling device


When a device is left to idle (no keystroke or mouse/touchpad movement), power saving policy kicks in through gnome-power-manager and dims the backlight and turns off the display. Other devices should autoidle themselves when not in use. This needs in this mode are identical needs in the active mode discussed below - shutting down unused hardware.


Suspend


The default action for Ubuntu when the laptop lid is closed it to try to suspend the device. New batteries can last several days in this state if it all works correctly.


However, it requires every device in the laptop to be put into a low-power/off state. These include the camera, backlight display, lcd display, wireless, bluetooth, usb ports, ethernet ports, mmc controller, graphics chip and cpu. In other words, each device driver has to do the right thing. If driver is buggy, a device/peripheral won't go in to a low power state and the high consumption could drain your battery quickly. Hence this work to fix drivers never really ends with hundreds of new components being introduced into the market each year that need drivers to work in Linux. Only a very small proportion of them, however, cause problems with suspend.


The most common problems related to suspend seen in Ubuntu are related to the backlight or LCD staying on or the graphics chip getting wedged. Video drivers are the cause of a large proportion of these problems, but one that we can't always fix by ourselves since documentation is not always available. Canonical works with graphics card vendors to ensure the new versions of the drivers support suspend and don't cause regressions with older graphics cards.


The Ubuntu Kernel Team provides a script to stress test suspend/resume on your machine.


One corner case we don't handle gracefully in Ubuntu is the case of running out of battery while suspended. We should detect this condition, automatically wakeup and hibernate the system to save state rather than just let the laptop die with unsaved state.


When we're actively using the device


Suspend/hibernate are only interesting when we're not actively using the mobile device. But we need to minimize power consumption during active use as well. This is often called runtime or dynamic power management. It involves turning off all unnecessary hardware or at least running it in low power mode.


Common examples include:

  • Turn off audio chip when not playing sounds (pm-utils enables powersave mode for Intel audio chips)
  • Turn off bluetooth chip when not paired
  • Turn off WLAN when not used for networking
  • Scale down the CPU voltage/frequency when you don't need the highest performance (cpufreq with ondemand governor enabled).
  • Idle the CPU when not in use for short periods of time (cpuidle and menu governor enabled)

Further enhancements being investigated and worked on upstream

  • Reducing display refresh rates (reclocking)
  • Clock gating (cutting clocks to parts of the graphics chip) to save power. This is a very common technique on ARM-based devices e.g. on your mobile phone
  • Memory hotplugging to switch off parts of the memory banks
  • USB autoidling (not supported on all usb devices)
  • Turning off unused ports e.g. External VGA

Lesswatts.org has several interesting articles on the topic of power management on Linux. Powertop is a tool that can be used to see what frequencies (p-states) and idle states (c-states) your cpu supports and what applications are responsible for waking up the CPU.


Miscellaneous optimisations

Undervolting allows us to reduce the voltage on certain processors as mentioned in Solution #6. But the patches have been rejected upstream because there is no easy way to tell which processors have these capabilities and which don't. Hence they won't be considered in Ubuntu.

Non-Intel platforms

While x86 processors rule the PC/laptop market, the mobile phone market is ruled by ARM processors. These processors are popular for their extremely low power consumption compared to x86 processors. In the past, they had limited performance, but lately you can find dual-core 1GHz ARM processors that would be able to handle the basic computing tasks of web browsing, email, chat, video/voice calls with ease.

While there aren't many netbook-like ARM-based devices in the market at present, many are expected to start showing up next year. Currently, one can get a Genesi smartbook that uses an older generation single-core Cortex-A8-based Freescale i.MX51 processor that can get ~5hours of battery on a 31Wh battery or a Toshiba AC100 that uses a new dual-core Cortex-A9-based Nvidia Tegra 250 processor that gets ~8h on a tiny 25Wh battery.

Organisations such as Linaro are working to speed up development of such devices on the ARM platform. Linaro partners such as Freescale, TI, IBM, ST-E and Samsung are working to make ARM a first-class Linux platform, not just for mobile phones, but for general-purpose computing devices too.

Disclaimer: I lead the Power Management working group in Linaro.

Topics of Interest


In conclusion, Ubuntu could focus efforts in the following areas to prolong the battery life on mobile devices and generally improve the Ubuntu experience on battery-powered devices:

  1. Teach g-p-m to prompt user when to plug/unplug power cord based on charging history (including deep discharges once in a while)
  2. Investigate ways to speed up hibernate to be faster than a fresh boot
  3. Allow graceful handling of the case where the battery runs out while suspended by waking up and hibernating the system
  4. Turn off bluetooth hardware by default, activate it only when user requests it and remember the active/inactive setting
  5. Turn off external VGA ports by default and activate it only upon user request
  6. Investigate whether graphics toolkits stop drawing to screen when screen is off
  7. Make sure Ubuntu on ARM-based chips runs as well as, if not better than the mobile OSes that've been traditionally used on these chips.

[1] http://batteryuniversity.com/learn/article/how_to_prolong_lithium_based_batteries

[2] http://www.apple.com/batteries/notebooks.html

[3] https://wiki.ubuntu.com/FoundationsTeam/BootPerformance/


8 comments:

Jeff said...

Here's another thought on preserving the battery by reducing the number of discharge cycles.

How about waking up from suspend and hibernating after something like 4 hours? This is a common use case when suspending overnight.

jam said...

Note that other OS's have a "manage my battery power" option. Which then automatically has your battery discharge (by some amount, maybe to 90%?) and then recharge, rather than trying to keep it topped off all the time.

D. said...

Nice summary. You may want to add these:

http://linux-tipps.blogspot.com/2010/10/disabling-fsync-in-laptopmode.html

http://linux-tipps.blogspot.com/2010/11/what-can-governor-adjustments-do-for.html

Here's my how to for poulsbo systems (many things apply to other systems): http://linux-tipps.blogspot.com/2010/06/saving-33-or-3-watts-of-power-with-my.html

And here's all my other power managerment articles.

Marten said...

To make things complicated, Li ion batteries last much longer if they are kept partially charged rather than fully. See, e.g., http://batteryuniversity.com/learn/article/how_to_prolong_lithium_based_batteries.

Frank said...

> The most common problems related to suspend seen in Ubuntu are related to the backlight or LCD staying on or the graphics chip getting wedged.

There is more noticeable problem: then notebook can't resume after suspend.
For example, in 2.6.35 kernel branch and later branches detected regression with many notebooks, primary Samsung Nxxx series: https://bugzilla.kernel.org/show_bug.cgi?id=21952

Ihar Filipau said...

Why everybody forgets about HDD??

I have used an Apple laptop for two week under Ubuntu 09.04 and the two most striking findings were: HDD runs hot, battery life is (bit less than) 2 hours instead of (bit more than) 4 hours.

After manually removing the redundant pieces of software I was managing to get HDD to sleep sometimes and was able to squeeze about 3 hours out of the single battery charge.

All over the net, people seem mistakenly forget and underrate that under Linux one of the major battery hogs is actually HDD. Under Mac OS X it remains cool and barely every spinning - while under Linux it runs hot and never sleeps: something always writes something to disk.

P.S. I were using "pidstat -d" to analyze the issue.

D. said...
This comment has been removed by the author.
D. said...

Check my link on fsync, that will fix your problem for all programs.