Who ate my battery?

Jeremy Bennett

The Ericsson T95 launched in 2001. It had a 720 mAh Li-Ion battery, a standby time of 300 hours and a talk time of 11 hours. A decade later the Sony-Ericsson Xperia X10 mini was launched. It has a 910 mAh Li-polymer battery, and using 3G, a standby time of approximately 285 hours and a talk time of approximately 3.5 hours with 3G.

Such is progress! Yet we cannot fault the hardware designers. Clock gating, dynamic voltage & frequency scaling and ever smaller components mean silicon is more energy efficient today than ever. And when thinking about energy, hardware designers know that the greatest energy saving come from starting at the highest abstraction level. Research by LSI Logic and Mentor Graphics found that the right architectural decisions could reduce energy usage by 80%, whereas optimizing at the detailed gate or layout stages saved just 5-10%.

Software can undo this at a stroke. Famously one Linux system wasted 70% of its energy waking up to blink the console cursor. I was part of a consumer electronics project where the software demands of a standard codec meant raising the processor frequency, and hence its operating voltage. With static leakage proportional to the square of the voltage and dynamic leakage proportional to frequency, the projected battery life plummeted, the project became non-viable and was cancelled.

Ultimately software controls the hardware. Choice of algorithms and data structures will have a huge impact on energy consumption. The traditional compiler focus on speed at the expense of all other considerations is very bad news for energy usage. Yet energy usage is invariably a secondary software requirement, if it is a requirement at all. We need a new way of thinking in software, and like our hardware colleagues, the further up the abstraction level we go, the better.

As part of the Energy Aware Computing Initiative (EACO), Embecosm funded research at Bristol University during the summer of 2012, to quantify rigorously the impact of compiler optimization options on energy consumption. Before we can improve energy performance of the code generated by compilers, we need to measure how they perform today. We looked at detailed energy consumption across a number of embedded processors as they ran a range of benchmark programs compiled with different optimizations selected. I’ll be covering this work and the results in more detail in future blog posts, but the good news is that the compiler offers considerable scope for reducing the energy consumption of compiled programs.

Meanwhile, when your smartphone next runs flat before the day is over, and you ask “who ate my battery?” you’ll know the answer. The software ate it.


One Response to “Who ate my battery?”

  1. Brody

    You are so right….

    I recently was involved in a project in which a smart sensor had to be developed with a maximum power budget of 10mW.
    Initially the sensor used around 6mW, but then the software development really kicked in and soon it spend more power than was available… and of course; the hardware was blamed.




Leave a Reply