energybook
I never used to worry about energy usage but over the last few years most of my code runs on smartphones, so it has become one of my top priorities. The trouble is I’ve never had any training or experience in the area, so I’ve had to learn how to do it from experience, other engineers, and the internet, most of which feels more like folklore than engineering. A few days ago I was trying to learn more about the shiny new Monsoon power monitor on my desk when I came across “Smartphone Energy Consumption” from Cambridge University Press.
I’ve now had a chance to read it, and it has helped fill in a lot of gaps in my education. I highly recommend picking up a copy if you’re facing any of the same problems, and to give you a taster here are some of the things I learned. Rest assured that any mistakes in here are my own, not the authors!
There are lots of different ways to measure battery capacity – joules, watt-hours, and milli-amp hours. If I’m getting my physics straight, 1 watt hour is 3,600 joules, and if you assume a rough voltage of 4V, 1 milli-amp hour is 0.001 * 4v * 60 * 60, or 14.4 joules. A typical phone battery might have 2,000 mAh, or about 29,000 joules.
Most phones can’t dissipate more than 3 watts of heat, so that’s a practical limit for sustained power usage. Wearables can have much lower limits.
There are two main ways power is used in mobile chips. Switching loss is the power used to change gate states in the silicon, and static loss is more like a steady leakage. Switching power decreases with the square of the voltage, so halving the voltage reduces its effect by 75%, whereas static power shrinks linearly. That leads to some interesting situations, where having two cores running at half the voltage and frequency (since lower clock frequencies allow lower voltages to be used) may take the same time to complete a task, but at half the power of a single higher-voltage core. Turning off parts of the chip entirely is the key to reducing static leakage.
There’s a great practical guide to wiring up Monsoons, exactly what I need right now! There’s also a great section on human-battery interaction, that I just skimmed, but which covers a lot of research. The key takeaway for me was that users get very annoyed if their battery starts draining more quickly than it used to, and will uninstall recent apps to fix the problem, so developer should be highly motivated to reduce their power consumption.
I found a lot of very useful estimates for components power usages scattered through the book. These are just rough guides, but they helped my mental modeling, so here are some I found notable:
  • An ARM A9 CPU can use between 500 and 2,000 mW.
  • A display might use 400 mW.
  • Active cell radio might use 800 mW.
  • Bluetooth might use 100 mW.
  • Accelerometer is 21 mW.
  • Gyroscope is 130 mW.
  • Microphone is 101 mW.
  • GPS is 176 mW.
  • Using the camera in ‘viewfinder’ mode, focusing and looking at a picture preview, might use 1,000 mW.
  • Actually recording video might take another 200 to 1,000 mW on top of that.
A key problem for wireless network communication is the ‘tail energy’ used to keep the radio active after the last communication, even when nothing’s being sent. This is vital for responsiveness, but it can be ten seconds for LTE, so apparently short communications can use a lot more energy than you’d expect. Sending a single byte can use a massive amount of power if it keeps the radio active for ten seconds after!
A Microsoft paper showed that over 50% of the power on several popular games is consumed by the ads they show!
There’s some interesting work on modeling the tradeoffs between computation offloading (moving work to the cloud from the phone) and communication offloading (doing more work on the device to reduce network costs). I’m a big believer that we should do more work on-device, so it was great to have a better foundation for modeling those tradeoffs. One example they give is using the Android SDK on a 1080p image to detect faces on-device, and taking 3.2 seconds and 9 joules, whereas sending the image to a nearby server was quicker, even with the extra power of network traffic.
Anyway, it’s a great piece of work so if this sort of information is useful, go pick up a copy yourself, there’s a lot more than I can cover here!