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.


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 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.




Thursday, September 09, 2010

cross-compilation re-redux


I don't think I'm going to get the cross-compilation article right, ever!

The repository has now moved to a Launchpad PPA.

So, for Maverick, you can do the following:
  • sudo apt-add-repository ppa:hrw/arm-cross-compiler
  • sudo apt-get update
  • sudo apt-get install gcc-arm-linux-gnueabi g++-arm-linux-gnueabigcc
Eventually, the idea is to replace this PPA as well, because the cross-compiler will be available in Ubuntu.

Wednesday, September 08, 2010

cross-compilation redux

It has been a while since my last blog post about developing for ARM platforms. We last looked at how to cross-compile the kernel. It is time to revisit that recipe.


I've been working with Linaro for the last few months to improve the toolchain, kernel and other components of Linux plumbing on ARM. There is also work to refactor the partner BSPs so that they can co-exist peacefully i.e. single kernel source tree, single u-boot tree, etc. We're just getting started but you can see the status for the first Linaro release in November.

Cross-compile toolchains

One of the first things that an embedded project has had to do is roll their own toolchain. This is obviously wasted time and effort. Linaro is attempting to fix this problem by pushing fixes into gcc upstream and by providing a standard toolchain for ARM development. This toolchain will take advantages of features of the ARMv7 architecture (NEON acceleration, various performance optimisations, SMP support, etc.). Some of this work in already available in the next release of Ubuntu (10.10 aka Maverick). Tarballs are available for other distributions.

If you're compiling your software for ARM, you should consider switching to this toolchain.

Cross-compile toolchain for Ubuntu 10.10 aka Maverick

The Toolchain working group at Linaro has made available a gcc-4.4 and gcc-4.5-based cross toolchains. For Maverick, just type the following in your terminal:
  • echo "deb ./" | sudo tee -a /etc/apt/sources.list.d/cross-compile.list
  • sudo apt-get update
  • sudo apt-get install gcc-arm-linux-gnueabi g++-arm-linux-gnueabi
Cross-compile toolchain for Ubuntu 10.04 LTS aka Lucid
If you're not brave enough to run Maverick beta, the same toolchain can be made to work on Ubuntu 10.04 LTS with some additional steps.
  • Install the maverick versions of two libraries: libmpfr4, libcloog-ppl0
  • Follow the steps for Maverick above
Cross-compiling the Ubuntu Kernel

Time to take the shiny cross-toolchain for a testdrive:
  • git clone git://
  • debuild -eCROSS_COMPILE=arm-linux-gnueabi- -b -aarmel
    Unfortunately this command breaks because of perf, I believe. It complains about libelf/libdw missing. I'll try to update with a dpkg-cross command when i get a chance.

Cross-compiling other stuff

And here is how you could use it to compile non-debian packages:
  • make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-


Monday, May 31, 2010

Flight pricing madness

I was looking at my options to takes a flight from Helsinki to Prague on a business trip. AFAICT, there are only 2 outgoing flights from Helsinki to Prague on my preferred day of departure - one leaving at 16:45 and the other at 17:35.

And I got price quotes from €232 to €1151! (Pictures linked below) WTF?

AFAICS, the flights are a code-share between Finnair and Czech Airlines. But can that be the only reason?

Anybody have a better explanation?

Thursday, August 06, 2009

Touchscreen = fail?

Do you have a touchscreen that isn't working in Ubuntu? We need your help!

We are trying to get as many touchscreens working as possible for Karmic.
Bug #317094 is attempting to collect hardware information about these them. As a first step, we'd like to enable the ones that can use the in-kernel usbtouchscreen driver.
  • Do you have a touchscreen?
  • Is it connected over USB? (lsusb is your friend)
  • Get the vendor and product id of the USB touchscreen (lsub)
  • Load the usbtouchscreen module and add the new id to it through sysfs
A made-up example follows (I don't have a touchscreen handy, sorry!)
  • example output from lsusb
Bus 005 Device 002: ID 0483:2016 SGS Thomson Microelectronics Fingerprint Reader
  • 0483 is the vendor id, 2016 is the product id
  • sudo modprobe usbtouchscreen
  • sudo sh -c "echo 0483 2016 > /sys/bus/usb/drivers/usbtouchscreen/new_id"
Replace the vendor and product id with what you found from lsusb.

If this makes your touchscreen work in Karmic, please reply on the bug with the ids and name of the touchscreen.

Wednesday, June 24, 2009

Speeding up boot on an upgraded system

So I have a laptop that I've been upgrading since Hardy (currently on Karmic Alpha) that I would like to boot faster. It has probably accumulated a lot of crufty daemons along the way that probably aren't being pre-loaded into memory. I picked up this tidbit from the fast boot expert. Add profile to your kernel command-line (at the grub prompt, press Esc e and then edit the line). This will update your system's readahead file list after a lot of disk churn. On my machine, it sped up boot by only about 5 seconds, but YMMV.

Also, if you have a machine or netbook with SSD (flash) disks, sreadahead might give you a boost. Again, apt-get install sreadahread is your friend
. sreadahead also schedules profiling of the system every month-or-so, so it keeps those boot-essential programs in the readahead cache always.

Friday, February 13, 2009

Ubuntu kernels, vanilla kernels, kerneloops

First, go read Pete's summary about the going-ons in Jaunty kernel-land.

The only bit I would like to add is to install the kerneloops package. This nifty little application will scan your logs for any crashes/warnings in the kernel and report them upstream as well as to Launchpad. This helps upstream and Ubuntu developers get an idea of what bugs a vast majority of their users sees and allows them to prioritize their time.

We are working toward getting it installed by default for beta, but for those of you that upgrade and keep a tight rein on what's installed please consider installing kerneloops.

sudo apt-get install kerneloops