Energy Management on Handheld Devices

December 5, 2003
Volume 1, issue 7

Download PDF version of this article PDF

Energy Management on Handheld Devices
MARC A. VIREDAZ, LAWRENCE S. BRAKMO,
and WILLIAM R. HAMBURGEN, HEWLETT-PACKARD LABORATORIES

Whatever their origin, all handheld devices share the same Achilles’ heel: the battery.

Handheld devices are becoming ubiquitous and as their capabilities increase, they are starting to displace laptop computers—much as laptop computers have displaced desktop computers in many roles. Handheld devices are evolving from today’s PDAs, organizers, cellular phones, and game machines into a variety of new forms. Although partially offset by improvements in low-power electronics, this increased functionality carries a corresponding increase in energy consumption. Second, as a consequence of displacing other pieces of equipment, handheld devices are seeing more use between battery charges. Finally, battery technology is not improving at the same pace as the energy requirements of handheld electronics. Therefore, energy management, once in the realm of desired features, has become an important design requirement and one of the greatest challenges in portable computing, and it will remain so for a long time to come.

Among today’s rechargeable batteries, lithium-ion cells offer the highest capacity. Introduced commercially by Sony in 1991, their capacity has improved by about 10 percent per year in recent years [1]. This rate of improvement is leveling off, however, and even with alternative materials and novel cell structures, major future improvement in rechargeable batteries is unlikely.

That is why battery suppliers and mobile system designers expect the eventual emergence of fuel-cell power sources and are investing accordingly. In its most basic form, a fuel cell combines hydrogen fuel with oxygen from the surrounding air to produce water and electricity. But hydrogen combusts easily and has low density, making it unattractive for most mobile applications. Instead, most efforts are directed toward using methanol as fuel and extracting the hydrogen with catalysts or high-temperature reforming [2].

While methanol-based fuel cells promise an order-of-magnitude higher energy density than chemical rechargeable batteries, serious development issues remain. Still, several manufacturers—Intermec Technologies and MTI MicroFuel Cells (working in partnership), NEC, and Casio—have promised initial product introductions in 2004 to 2005. Some of these early fuel cells will be used in handheld systems, but most will be for laptop computers where the fuel cell’s hardware complexity can be amortized over a larger system. Widespread adoption of fuel cells in portable electronics is not expected until the end of the decade. Experience has shown that users’ expectations evolve along with systems’ capabilities. Even the adoption of fuel cells will probably not be enough to slake mobile users’ thirst for energy or diminish the importance of energy management.

Although the words power and energy are often used interchangeably in casual conversation, it is very important to understand the difference between these two concepts. The power used by a device is the energy consumed per time unit. Conversely, energy is the time integral of power. Since a battery stores a given quantity of energy, the goal of energy management (unfortunately, often referred to as power management) is to minimize the amount of energy required to perform each task satisfactorily.

In some cases, minimizing the power also minimizes energy, but, as will be shown, this is not always the case. Some tasks will require less energy to complete when being performed at high speed and high power for a short duration rather than at low speed and low power for a longer period of time.

However, fixed-duration tasks—such as playing audio or video—form an important class where the energy required is directly proportional to the average power consumed (since the duration of the task is, by definition, constant). This class also includes waiting, whether waiting for user input when the device is on or keeping data in memory and the clock ticking when the device is off. For this class of tasks, focusing on minimizing power will minimize energy.

Energy usage in handheld devices

To achieve useful energy management, it is important to understand how and where energy is used in handheld devices. Unfortunately, little published data is available. A power study [3] has been published for the Itsy [4], a prototype pocket computer developed by our team at the former Compaq Laboratories in Palo Alto, California. In this study, the power usage of Itsy is broken down into itscomponents for a variety of workloads ranging from idling to decoding and playing MPEG video.

Figure 1 shows the minimum power consumed by several components or groups of components (usually attained during sleep mode), as well as the low and high power-consumption figures for all the non-sleep-mode benchmarks used in this study. These power ranges are representative of real-life power consumption, since the benchmarks range from idle mode to applications stressing the limits of most components.

In most respects, Itsy is similar to its contemporary commercial handheld devices based on Intel’s StrongARM processors. Therefore, its power usage should also be representative of these devices. Itsy differs considerably from its commercial counterparts in one respect, however: the display. Itsy uses a passive-matrix gray-scale liquid crystal display (LCD), optimized to be used without backlight in most lighting conditions (only under very dim lighting is the backlight necessary).

On the other hand, many commercial handheld devices use active-matrix color LCDs. Although these displays are usually reflective or transflective and can be used with ambient light only, it has been found that most users turn the back- or frontlight on, at least to low brightness, for more contrast and brighter more-saturated colors. To account for this difference, figure 1 also presents the power for the display and frontlight of the Compaq iPAQ h36xx, a device that is otherwise similar to Itsy.

Another significant difference is that Itsy does not have any built-in wireless capability, while today many handheld users want wireless communication, either as an accessory or, for the latest handheld devices, built into the system. Figure 1 also shows the power consumption of a popular wireless (IEEE 802.11b) PC card [5], which can be used as an accessory on handheld devices such as the iPAQ H36xx.

Finally, while it would have been preferable to present data for a more recent device with a more modern processor, no similarly comprehensive data has been published. Although based on newer technology, the architecture of these devices is similar enough to Itsy’s that a power breakdown should not look qualitatively much different.

Energy-saving techniques

The most noticeable characteristic of figure 1 is that the minimum power values for all components are at least an order-of-magnitude smaller that the maximum ones. It suggests that the obvious technique of turning off a sub-unit when it is unused can actually be very effective. Although conceptually simple, this scheme requires a careful analysis of the OS (operating system). As our experience with Itsy showed, achieving optimal energy savings requires well-structured software and a lot of careful work.

To achieve this goal, system hardware should be designed as a collection of interconnected building blocks that can function independently and be independently powered on and off. Current handheld devices only partially fulfill this requirement. Peripheral building blocks (communication ports, audio input and output, display, etc.) can usually be disabled or turned off when unused. However, it is generally not possible to turn off the central building blocks, such as the processor or memories, except by putting the whole system in sleep mode.

With the trend of putting more and more functionality into the processor, new processor architectures must keep internal building blocks independent from a power point of view. It would also be useful if integrated-circuit manufacturers would specify the power behavior of sub-units. Today’s specifications usually provide information only on how to enable or disable a sub-unit or how to change its parameters (speed, etc.), but not on how such actions will affect the power consumption. Without such data, software developers must resort to guesses or perform their own measurements.

One of the interesting findings of the Itsy power study is that the interplay of different sub-units with different power characteristics sometimes results in surprising and counterintuitive behavior [3]. This suggests that realtime power measurement hardware might enable the software to make better energy-use decisions.

Processor, Memory, and Peripherals

Power states. As shown in figure 1, the processor can be responsible for a large percentage of the system’s power consumption. The processors in today’s handheld devices provide mechanisms to reduce their power usage by reducing the available performance. There are typically three major power states: run, idle, and sleep. Each of the major states can itself consist of one or more minor states. For example, there may be multiple frequencies to choose from for the running state. Similarly, there may be multiple levels of the sleep state, each with a different set of components turned off.

Figure 2 shows the major power states available on the StrongARM SA-1100, the processor used on Itsy. The major run state has 20 minor states, two core frequencies for each of the 10 supported frequencies used by the rest of the processor. The idle state has 10 minor states, one per supported frequency. The transitions between the run state and the idle or sleep state are under software control. The transition from the idle state to the run state is triggered by an interrupt. The transition from the sleep state to the run state occurs as a result of a realtime clock (RTC) alarm or an external interrupt.

Three factors need to be considered when looking at the energy implications of using a given processor state:

The performance available in this state
The latency required to enter and exit this state (usually from/to the run state)
The power consumed by the processor in this state

From a software point of view, the idle state is considered a lightweight state because of the small entry and exit latencies, while the sleep state has much larger latencies and is considered a heavyweight state. Table 1 shows the performance, latencies, and power for each of Itsy’s StrongARM SA-1100 states.

When looking at table 1, note that the sleep state has two minor states, depending on whether or not the main clock is left enabled. Turning it off saves power but increases the latency to exit the sleep state from 10 to 157 milliseconds (ms). Another important issue is that these latencies are only hardware latencies; in the case of the sleep state, you should consider the sometimes-significant latencies resulting from saving and restoring OS state.

Table 1
State	Performance	Hardware latencies	Electrical power
Sleep	Interrupts are detected and can awake the processor.	Entering sleep: 150 µsExiting sleep: 10–157 ms	7.18 mW
Idle	No instructions are executed; interrupts put the processor in the run state.	Entering idle: < 10 cycles Exiting idle: < 10 cycles	55.5 mW at 59 MHz 81.9 mW at 133 MHz 95.5 mW at 192 MHz
Run	Performance is a function of processor frequency.	N/A	Depends on the workload.

Frequency and voltage scaling. Dynamic frequency scaling (DFS) is a technique that seeks to reduce power consumption by changing the processor frequency based on the requirements of the executing application. For fixed-duration tasks, especially waiting, this usually results in a proportional reduction of energy use. For other tasks, because of the corresponding increases in execution time, DFS could either save or waste energy depending on second-order effects. To guarantee energy savings, the processor voltage must be changed at the same time as the frequency. This technique is referred to as dynamic voltage-frequency scaling (DVFS), or as dynamic voltage scaling (DVS).

The importance of DVFS arises from the fact that the power consumed by a processor is proportional to the frequency and to the voltage squared:

P µ f · v

As a first approximation, a given task (with no waiting) takes a fixed number of processor cycles, so the energy used per task is proportional to the voltage squared.

Older processors did not support voltage scaling (although the StrongARM processor was only specified to allow frequency scaling, several experimental systems, including Itsy, used it to implement DVFS). Newer processors such as Intel’s XScale are specified to operate at a few different voltage points, with different maximum frequencies.

DVFS and DFS algorithms strive to change the frequency without affecting the user’s perception of system response time. Frequency changes usually occur at a fixed rate—for example, every 10 ms—and are based on a prediction of the processing requirements (workload) until the next decision point. Although many algorithms have been proposed [6,7], DVFS (or even DFS) is rarely implemented in general-purpose commercial handheld systems.

Instead, handheld devices that support frequency scaling have taken a more static approach, changing processor frequency only as a result of a major event such as a user request or low battery condition. The lack of DVFS/DFS in commercial handheld systems is due to many reasons, including the added complexity of correctly implementing DVFS/DFS and the potential for increased system response time.

There are also side effects associated with frequency changes in many current processors. These processors are highly integrated and include many I/O components, such as LCD controller and serial ports, which can misbehave during or after a frequency change. To eliminate this problem, some (such as the XScale processors) can be programmed with two core frequencies, where one is a multiple of the other and the processor can switch between the two without affecting the I/O components.

Memory. One interesting finding of the Itsy power study [3] is that the energy cost of refreshing dynamic random-access memory (DRAM) is small compared with the cost of accessing it. Therefore, increasing the size of the memory does not result in an important energy penalty. This is, however, not the case in sleep mode, where selectively powering down part of the memory would be beneficial. Although operating systems have traditionally not implemented any mechanisms for this purpose, you could compress the memory content or otherwise free memory (e.g., require that some applications save their state and exit) to take advantage of such a feature.

Any techniques to reduce the number of memory accesses would also be beneficial. Traditionally, caches have been used for this purpose. Caches, however, are themselves memory arrays, and the energy cost of accessing a cache will increase with its size. In the future, it is possible that cache sizes for handheld processors will be optimized to reduce energy consumption rather then access time.

Display. As illustrated by figure 1, the display back- or frontlight can easily dominate the not insignificant power used by the display itself. Even at one-quarter brightness, the iPAQ H36xx’s frontlight is a major power consumer.

Some of this lamp power becomes the photons that make up the image; hence, some power use is unavoidable in low lighting conditions. With good ambient lighting, however, the use of a back- or frontlight could be completely avoided if LCDs had better reflective characteristics.

While cold cathode fluorescent lamps (CCFLs) are typically used for illuminating color LCDs in handheld products, light emitting diodes (LEDs) are gaining a foothold. While today’s white LEDs have less than half the efficiency of CCFLs, they are rapidly improving and dropping in price [8], and they are being used where the LED’s lower efficiency is offset by simplified light-guide optics and elimination of the CCFL’s high-voltage power converter.

Independently from display hardware improvements, other energy-saving techniques might also be useful. For instance, a typical back- or frontlight illuminates an LCD uniformly. The full brightness of the light, however, is efficiently used for light pixels only. For dark pixels, the light is mostly absorbed and the corresponding power wasted. Naehyuck Chang and his team proposed dimming the back- or frontlight while compensating by increasing the brightness and contrast when displaying dark pictures [9]. They also proposed software techniques to reduce the power consumption of the LCD driver.

Organic light-emitting diode (OLED) displays are a promising new technology for the near future. Since these displays are emissive, however, they cannot make use of ambient light. A more proactive form of energy management is possible for OLED displays: Subu Iyer and colleagues suggest darkening the parts of the screen that are not actively used by an application [10]. Although this technique was shown to be effective on laptop computers, newer work by the same authors has indicated that large power savings might also be possible on handheld devices. Users could also choose window color schemes to reduce the number of bright pixels (e.g., light text over dark background).

Finally, further energy reduction could be achieved by changing the usage model for some handheld devices. A viewfinder or head-mounted display uses a tiny display element to produce a large virtual image [11] and uses significantly less power than direct-view handheld displays.

Audio system. Although microphone input uses little power, audio output—particularly using loudspeakers—can use appreciable power. In recent years, highly efficient switching (class D) amplifiers have been displacing traditional linear amplifiers on portable electronics for all but audiophile applications. The remaining power is mostly used to produce the sound, and little can be done if speakers remain the favored audio-output interface. As with displays, however, energy could be saved by changing the usage model, in this case by using headsets.

Wireless networking. Wireless networking is becoming an important feature in handheld devices. The most popular short-range wireless technologies are Bluetooth (BT) and IEEE 802.11b (or WiFi). Low-power BT is a short-range technology, having a typical range of 10 meters, with a bandwidth of less than 1 megabit per second (Mbps). One of its main advantages is the low power consumption, on the order of 100 to 200 milliwatts (mW) for transmission and reception, 10 to 20 mW in idle mode, with even lower power modes (e.g., sniff, hold, or park) available during sporadic use.

IEEE 802.11b has a much longer range, normally about 100 meters, and a much higher bandwidth (11 Mbps) at the cost of much higher power consumption. For example, an IEEE 802.11b wireless PC Card was measured at about 60 mW in sleep (doze) mode, 805 mW in idle mode, 950 mW while receiving, and 1,400 mW while transmitting [5].

Today’s most common technology for wide-area wireless networking is General Packet Radio Service (GPRS). GPRS uses a mobile telephone network to send and receive information and has a theoretical maximum speed of about 170 Mbps. Typical speeds are much less, in the range of 10 to 50 kilobits per second (Kbps). Higher speeds are expected in the future with the introduction of enhanced data rates for GSM evolution (EDGE) and Universal Mobile Telephone System (3GSM).

Reducing energy consumption in a wireless subsystem is achieved by spending as much time as possible in low power states. As with processor-state switching, however, it is important to take into account the energy cost of transitions into and out of these lower power states.

Current operating systems

Current operating systems usually implement three power states substantially equivalent to the run, idle, and sleep states described earlier for Linux. They are often named differently: Windows CE 3.0 calls them on, idle, and suspend; Symbian calls them run, idle, and standby; and Palm OS calls them run, doze, and sleep.

Most operating systems use an idle thread or process running at the lowest possible priority that is entered whenever there is no useful work to be done. The function of the idle thread is to put the processor into its idle state. The OS enters its sleep state either through a user action, such as pressing a button, or through an inactivity timer. Before the OS can put the processor into its sleep state, it must first save some portion of the OS state, such as the value of some processor control registers. When the OS resumes, either by user action or by an RTC alarm (e.g., an appointment alarm), the OS must restore the processor registers that were saved.

Operating systems also support turning off individual components when they are not being used. For example, the audio subsystem could be turned off when no application is using it.

Linux is often used for prototyping, thanks to its open source model, which allows anyone to implement and explore novel energy management approaches.

Conclusion

As people increasingly rely on handheld devices, good energy management is becoming necessary to squeeze the most out of a battery. A plethora of ideas have been proposed and tested by researchers in academia and industry, but relatively few have made their way into commercial products. The field is still in its infancy, and interesting ideas continue to blossom.

Power/energy studies, which have been sadly lacking, are necessary to understand how energy is actually used. Very little data is available and more published studies are badly needed. Another requirement is better tools to track how energy is used [12], in particular the capability to evaluate power consumption in real time.

There is also a chasm in that power measurements have traditionally been in the hands of hardware engineers, while energy management is usually the responsibility of software developers. Hardware engineers need to provide energy-tracking tools that software developers can easily use. At the same time, software engineers need to acquire a better understanding of how the hardware uses energy.

In many respects, the energy-management field is at the same stage as performance evaluation decades ago, when a similar gulf existed between hardware engineers who understood “where cycles were being used” and software engineers who wrote compilers and applications. Perhaps within a few years “energy-management engineers” will be as numerous as performance engineers are today and will help bridge this still-yawning gap.

References

1. Linden, D. and Reddy, T. Secondary Batteries—Introduction. In Handbook of Batteries, ed. D. Linden and T. Reddy, pp. 22.3–22.24. New York, NY: McGraw-Hill, 3rd edition, 2002; http://www.knovel.com/knovel/databook/pdf/627/59788_22.pdf.

2. Riezenman, M. Mighty mites. IEEE Spectrum 40, 6 (June 2003), 30–33; http://www.spectrum.ieee.org/spectrum/jun03/features/mm.html (subscription required).

3. Viredaz, M. and Wallach, D. Power evaluation of a handheld computer. IEEE Micro 23, 1 (Jan.-Feb. 2003), 66–74; http://dlib.computer.org/mi/books/mi2003/pdf/m1066.pdf (subscription required).

4. Hamburgen, W., Wallach, D., Viredaz, M., Brakmo, L., Waldspurger, C., Bartlett, J., Mann, T., and Farkas, K. Itsy: Stretching the bounds of mobile computing. Computer 34,4, (April 2001), 28–36, IEEE Computer Society; http://dlib.computer.org/co/books/co2001/pdf/r4028.pdf (subscription required).

5. Shih, E., Bahl, P., and Sinclair, M. Wake on Wireless: An event-driven energy saving strategy for battery-operated devices. In Proceedings of the Eighth Annual International Conference on Mobile Computing and Networking, pp. 160–171. Atlanta, GA: ACM Press, Sept. 2002; http://portal.acm.org/ft_gateway.cfm?id=570666&type=pdf (account and password required).

6. Weiser, M., Welch, B., Demers, A., and Shenker, S. Scheduling for reduced CPU energy. In Proceedings of the First Symposium on Operating Systems Design and Implementation, pp. 13–23. Monterey, CA: Usenix, Nov. 1994; http://www.ubiq.com/hypertext/weiser/ReducedEnergyScheduling.ps.

7. Govil, K., Chan, E., and Wasserman, H. Comparing algorithms for dynamic speed-setting of a low-power CPU. In Proceedings of the First International Conference on Mobile Computing and Networking, pp. 13-25. Berkeley, CA: ACM Press, Nov. 1995; http://portal.acm.org/ft_gateway.cfm?id=215546&type=pdf (account and password required).

8. Hara, Y. White LED lamp market brightens. EE Times, (July 18, 2002); http://www.eetimes.com/story/OEG20020718S0013.

9. Choi, I., Shim, H., and Chang, N. Low-power color TFT LCD display for handheld embedded systems. In Proceedings of the 2002 International Symposium on Low Power Electronics and Design, pp. 112–117. Monterey, CA: ACM Press, Aug. 2002; http://portal.acm.org/ft_gateway.cfm?id=566440&type=pdf (account and password required).

10. Iyer, S., Luo, L., Mayo, R., and Ranganathan, P. Energy-adaptive display system designs for future mobile environments. In Proceedings of the First International Conference on Mobile Systems, Applications, and Services, pp. 245–258. San Francisco, CA: ACM, Usenix, May 2003; http://www.usenix.org/events/mobisys03/tech/full_papers/iyer/iyer.pdf (subscription required).

11. The fusion of PDA portability and laptop utility. Whitepaper, Rochester, NY: Interactive Imaging Systems, 2001; http://www.iisvr.com/downloads/Fusion1.pdf.

12. Chang, F., Farkas, K., and Ranganathan, P. Energy-driven statistical sampling: Detecting software hotspots. In Power-Aware Computer Systems, ed. B. Falsafi and T.Vijaykumar, vol. 2325 of Lecture Notes in Computer Science, pp. 110–129. Heidelberg, Germany: Springer-Verlag Heidelberg, 2003 (Revised papers from PACS 2002); http://www.springerlink.com/link.asp?id=yfj75qh16nkr3ra3.

MARC A. VIREDAZ is a researcher at Hewlett-Packard Laboratories. He has a Ph.D. in computer engineering from the Swiss Federal Institute of Technology at Lausanne (EPFL). He codesigned the Itsy hardware with W.R. Hamburgen. His research interests include handheld and mobile computing, hardware design, low-power systems, and computer architecture.

LAWRENCE S. BRAKMO is a researcher at Hewlett-Packard Laboratories. He has an M.S. in mathematics and a Ph.D. in computer science from the University of Arizona. He was one of the original OS developers for Itsy, collaborating in the Linux port and on energy management extensions to the OS. His current research interests include energy/power management, handheld and mobile computing, operating systems, and computer networks.

WILLIAM R. HAMBURGEN is a researcher at Hewlett-Packard Laboratories. He has a B.S. from the Massachusetts Institute of Technology and M.S.M.E. degree from Stanford University. His interests encompass system design, power, and packaging. Prior work includes packaging the BIPS 115W bipolar ECL microprocessor and initiating and leading the Itsy handheld computer project.

Originally published in Queue vol. 1, no. 7—
Comment on this article in the ACM Digital Library