An Analysis of Power Consumption in a Smartphone

An Analysis of Power Consumption in a Smartphone Aaron Carroll NICTA and University of New South Wales Aaron.Carroll@nicta.com.au Gernot Heiser NICTA, University of New South Wales and Open Kernel Labs gernot@nicta.com.au Abstract Mobileconsumer-electronicsdevices,especiallyphones, are powered from batteries which are limited in size and therefore capacity. This implies that managing energy well is paramount in such devices. Goodenergymanagementrequiresagoodunderstand-ing of where and how the energy is used. To this end we present a detailed analysis of the power consumption of a recent mobile phone, the Openmoko Neo Freerunner. We measure not only overall system power, but the exact breakdown of power consumption by the device’s main hardwarecomponents. Wepresentthispowerbreakdown for micro-benchmarks as well as for a number of realis-tic usage scenarios. These results are validated by over-all power measurements of two other devices: the HTC Dream and Google Nexus One. We develop a power model of the Freerunner device and analyse the energy usage and battery lifetime under a number of usage patterns. We discuss the significance of the power drawn by various components, and identify themostpromisingareastofocusonforfurtherimprove-mentsofpowermanagement. Wealsoanalysetheenergy impact of dynamic voltage and frequency scaling of the device’s application processor. 1 Introduction Mobile devices derive the energy required for their op-eration from batteries. In the case of many consumer-electronicsdevices,especiallymobilephones,batteryca-pacity is severely restricted due to constraints on size and weight of the device. This implies that energy effi-ciency of these devices is very important to their usabil-ity. Hence, optimal management of power consumption of these devices is critical. At the same time, device functionality is increasing rapidly. Modern high-end mobile phones combine the functionality of a pocket-sized communication device with PC-like capabilities, resulting in what are generally referred to as smartphones [11]. These integrate such di-verse functionality as voice communication, audio and video playback, web browsing, short-message and email communication, media downloads, gaming and more. The rich functionality increases the pressure on battery lifetime, and deepens the need for effective energy man-agement. A core requirement of effective and efficient manage-mentofenergyisagoodunderstandingofwhereandhow the energy is used: how much of the system’s energy is consumed by which parts of the system and under what circumstances. In this paper we attempt to answer this question and thus provide a basis for understanding and managing mobile-device energy consumption. Our approach is to measure the power consumption of a modern mobile de-vice, the Openmoko Neo Freerunner mobile phone, bro-kendowntothedevice’smajorsubsystems,underawide range of realistic usage scenarios. Specifically, we produce a breakdown of power distri-butiontoCPU,memory,touchscreen,graphicshardware, audio, storage, and various networking interfaces. We derive an overall energy model of the device as a func-tion of the main usage scenarios. This should provide a good basis for focusing future energy-management re-search for mobile devices. Furthermore, we validate the results with two addi-tional mobile devices at a less detailed level: the HTC Dream and Google Nexus One. Along with the Freerun-ner, these three devices represent approximately the last three to four years of mobile phone technology. The paper is structured as follows. In Section 2 we describe our measurement platform and benchmarking methodology. Section 3 describes each experiment and presents the results, and in Section 4 we perform a coarse-grained validation of the results. We then analyse this data in Section 5. Section 6 surveys existing work. Finally, we conclude in Section 7. 2 Methodology GSM WiFi Our approach to profiling energy consumption is to take physical power measurements at the component level on a piece of real hardware. In this section, we describe the hardware and software used in the experiments, and explain our benchmarking methodology. There are three elements to the experimental setup: the device-under-test (DuT), a hardware data acquisition (DAQ) system, and a host computer. Amp Codec GPS Bluetooth serial SDIO Applications I2C Processor serial NAND USB SDRAM 2.1 Device under test Host bus The DuT was the Openmoko Neo Freerunner (revision A6) mobile phone. It is a 2.5G smartphone featuring a large, high-resolution touchscreen display, and many of the peripherals typical of modern devices. Table 1 lists itskeycomponents. Thenotabledifferencesbetweenour deviceandamodernsmartphonearethelackofacamera and 3G modem. LCD Graphics SDRAM SD Card Figure1: ArchitectureoftheFreerunnerdevice,showing the important components and their interconnects. Component SoC CPU RAM Flash Cellular radio GPS Graphics LCD SD Card Bluetooth WiFi Audio codec Audio amplifier Power controller Battery Specification Samsung S3C2442 ARM920T @ 400MHz 128MiB SDRAM 256MiB NAND TI Calypso GSM+GPRS u-blox ANTARIS 4 Smedia Glamo 3362 Topploy 480640 SanDisk 2GB Delta DFBM-CS320 Accton 3236AQ Wolfson WM8753 National Semiconductor LM4853 NXP PCF50633 1200mAh, 3.7V Li-Ion 2.2 Experimental setup To calculate the power consumed by any component, both the supply voltage and current must be determined. To measure current, we inserted sense resistors on the power supply rails of the relevant components—this is relativelysimpleontheDuTselected,sincemostofthem havebeendesignedwithplaceholdersforsenseresistors, factory-populated with 0. Where this was not the case, chokeinductorscouldbereusedinthesameway. Inboth cases, we replaced the part with a current-sense resistor selected such that the peak voltage drop did not exceed 10mV, which in all cases is less than 1% of the supply voltage and therefore presents an acceptably small per-turbation. Withaknownresistanceandmeasuredvoltage drop, current can be determined by Ohm’s law. Table 1: Freerunner hardware specifications. This device was selected because the design files, par-ticularly the circuit schematics [7], are freely available. This is critical for our approach to power measurement, whichreliesonunderstandingthepowerdistributionnet-work at the circuit level. For this reason, few other de-vices would be suitable. The high-level architecture of the Freerunner is shown in Figure 1. The total system memory is split equally be-tween two banks, one external RAM package, and one on-chip. All peripherals except the graphics chip com-municate with the application processor (CPU) by pro-grammed I/O over various serial buses. The other devices studied, the HTC Dream (G1) and Google Nexus One (N1), are described in Section 4. To measure the voltages, we used a National Instru-ments PCI-6229 DAQ, to which the sense resistors were connected via twisted-pair wiring. The key characteris-tics of this hardware are summarised in Table 2. Characteristic Value Max. sample rate 250kS/s Input ranges 0:2V, 1V, 5V and 10V Resolution 16b Accuracy 112V @ 0.2V range 1.62mV @ 5V range Sensitivity 5.2V @ 0.2V range 48.8V @ 5V range Input impedance 10G Table 2: National Instruments PCI-6229 DAQ specifica-tions [6]. The sense-resistor voltage drops were sampled differ-entially at the 0:2V input range. We used the same physical connections to measure supply voltages; these were taken relative to ground from the component side of the resistors, in the 5V range. Wewereabletodirectlymeasurethepowerconsumed by the following components: CPU core, RAM (both banks), GSM, GPS, Bluetooth, LCD panel and touch-screen, LCD backlight, WiFi, audio (codec and ampli-fier),internalNANDflash,andSDcard. Sincethegraph-icsmodulehadtoomanysupplyrailstomeasuredirectly, we instead used a combination of direct and subtractive measurements. PowertotheDuTwassuppliedthroughabenchpower supply connected to the phone’s battery terminals so we did not need to deal with battery management. This also prevents the OS’s power policies from interfering with the benchmarks. Total system power consumption was measured at this point by inserting a sense resistor be-tween the supply and the phone. For the G1 and N1 we measuredtotalsystempowerbyinsertingasenseresistor between the device and its battery. Measuring backlight power required special attention, because its supply voltage (10–15V, depending on the brightness) far exceeded the maximum range supported by our DAQ hardware. To resolve this, we pre-scaled the backlight voltage with some external circuitry, consist-ing of a high-input-impedance voltage follower feeding a fixed voltage divider. This brought the voltage within the 5V range. 2.2.1 Voltage regulation efficiency Our measurement approach yields the power directly consumed by each component. However, a certain amount of additional power is lost in converting the sup-ply (i.e. battery) voltage to the levels required by the components. We have not included this factor in the results reported, because the conversion efficiencies are unknown. However, based on the data sheet of a similar part (the NXP PCF 50606), the efficiency conversion is likely to be in the range of 75–85%, depending on the current drawn. Because of this, we differentiate between “total power”, measured at the battery, and “aggregate power”, measured as the sum of individual component measure-ments. The latter assumes no power is consumed in the non-instrumented components, and while we haven’t beenabletomeasurepreciselywhattheircontributionis, it is certainly less than 10%, and probably within a few percent of the aggregate consumption. One exception to this is the backlight boost converter, the efficiency of which we measured to be 67%. We de-terminedthecauseofthispoorefficiencytobeheatingin anexternalcomponent. Wefoundnoevidencetosuggest this is an issue for any of the other voltage regulators. 2.3 Software The DuT ran the Freerunner port of the Android 1.5 op-erating system [1] using the Linux v2.6.29 kernel. Ex-cept for the CPU micro-benchmark, the kernel was con-figured with the ondemand frequency scaling governor, using 100MHz and 400MHz—the only two frequencies supported by both the hardware and OS. On the host system we ran the power-data collection software which interfaced with the National Instruments DAQmxBase 3.3 library to collect raw data from the DAQ, aggregate it, and write the result to file for post-processing. Each data point collected was an average of 2000 consecutive voltage samples. We configured the tool such that a complete power snapshot of the system could be generated approximately every 400ms. The benchmarks were coordinated on the host ma-chine, which communicated with the DuT via a serial connection. Itwasresponsibleforexecutingbenchmarks on the DuT, synchronising the power measurement soft-ware with the benchmark, and collecting other relevant data. 2.4 Benchmarks We ran two types of benchmarks. First, a series of micro-benchmarks designed to independently charac-terise components of the system, particularly their peak and idle power consumption. Second, we ran a series of macro-benchmarks based on real usage scenarios. For low-interactivity applica-tions (e.g. music playback), we simply launched them from the command line. For interactive applications, such as web browsing, we took a trace-based approach. A trace consisted of a sequence of input events, in-cluding a time-stamp, the name of the device provid-ing the input (the touchscreen or one of two push-buttons), and for touchscreen events, the coordinates of the touch. The Linux kernel provides this informa- tion by reading from the /dev/input/event* de-vice files. To collect the trace, we used the target ap- plication normally, while in the background storing the input events to file. We then replayed the events under benchmarking conditions by writing the collected data to the /dev/input/event* files at the correct time. Although this approach does bypass the hardware and interrupt paths that would usually be followed for a touchscreen event, our measurements showed the addi-tional power to be negligible. The vast majority of en-ergy required to handle a touchscreen event is consumed in delivering it from the kernel to software. 35 30 25 20 15 10 5 0 Figure 2: Power breakdown in the suspended state. The aggregate power consumed is 68.6mW. 3 Results 3.1 Baseline cases Prior to running any benchmarks, we established the baseline power state of the device, when no applications are running. There are two different cases to consider: suspended and idle. For the idle case, there is also the application-independentpowerconsumptionoftheback-light to consider. 3.1.1 Suspended device A mobile phone will typically spend a large amount of time in a state where it is not actively used. This means that the application processor is idle, while the commu-nications processor performs a low level of activity, as it must remain connected to the network be able to re-ceive calls, SMS messages, etc. As this state tends to dominate the time during which the phone is switched on, the power consumed in this state is critical to battery lifetime. The Android OS running on the application proces-sor aggressively suspends to RAM during idle periods, whereby all necessary state is written to RAM and the devices are put into low-power sleep modes (where ap-propriate). To quantify power use while suspended, we forced the device into Android’s suspended state and measured the power over a 120 second period. Figure 2 shows the results, averaged over 10 iterations. The av-erage aggregate power is 68.6mW, with a relative stan-dard deviation (RSD) of 8.2%. The large fluctuations are largely due to the GSM (14.4% RSD) and graphics (13.0%) subsystems. The GSM subsystem power clearly dominates while suspended,consumingapproximately45%oftheoverall power. Despite maintaining full state, RAM consumes negligible power—less than 3mW. Note that the GSM 90 80 70 60 50 40 30 20 10 0 Figure 3: Average power consumption while in the idle state with backlight off. Aggregate power is 268.8mW. subsysteminourdevicedoesnotusesystemmemory—it has its own bank of RAM which we include in the GSM power measurements. 3.1.2 Idle device The device is in the idle state if it is fully awake (not sus-pended) but no applications are active. This case consti-tutes the static contribution to power of an active system. We run this case with the backlight turned off, but the rest of the display subsystem enabled. Figure 3 shows the power consumed in the idle state. As with the suspend benchmark, we ran 10 iterations, each of 120 seconds in the idle state. Power consumed in this state was very stable, with an RSD of 2.6%, in-fluenced largely by GSM, which varied with an RSD of 30%. All other components showed an RSD below 1%. Figure 3 shows that the display-related subsystems consume the largest proportion of power in the idle state—approximately 50% due to the graphics chip and LCDalone,andupto80%withbacklightatpeakbright-ness. GSMisalsoalargeconsumer,at22%ofaggregate power. 3.1.3 Display Figure 4 shows the power consumed by the display backlight over the range of available brightness levels. That level is an integer value between 1 and 255, pro-grammed into the power-management module, used to control backlight current. Android’s brightness-control user-interface provides linear control of this value be-tween 30 and 255. The minimum backlight power is approximately 7.8mW, the maximum 414mW, and a centred slider cor-respondstoabrightnesslevelof143,consuming75mW. The backlight consumes negligible power when disabled (as in the above idle benchmarks). 450 400 350 300 250 200 150 100 50 0 0 50 100 150 200 250 Brightness level 200 180 160 140 120 100 80 60 40 20 0 CPU(100MHz) RAM(100MHz) CPU(400MHz) RAM(400MHz) Figure4: Displaybacklightpowerforvaryingbrightness levels. We also measured how the content displayed on the LCD affected its power consumption: 33.1mW for a completely white screen, and 74.2mW for a a black screen. Display content can therefore affect overall power consumption by up to 43mW. Figure 5: CPU and RAM power when running SPEC CPU2000 micro-benchmarks, sorted by CPU power. we do not expect the benchmarks to behave similarly on the different platforms, our aim is only to select bench-marks with different characteristics. 3.2 Micro-benchmarks The SPEC CPU2000 benchmarks ultimately selected are equake, vpr, gzip, crafty and mcf. AsmentionedinSection2.4,weusedmicro-benchmarks to determine the contribution to overall power from var-ious system components. Specifically we used bench-marks to exercise the application processor (CPU and memory), the flash storage devices, and the network in-terfaces. 3.2.1 CPU and RAM TomeasureCPUandRAMpower, weranasubsetofthe SPEC CPU2000 suite. There are several reasons for not running all benchmarks of the suite. Firstly, we could only use benchmarks which we could build and run on the Android OS, which rules out those written in C++ or Fortran, due to Android’s lack of run-time support for these languages. They also needed to fit into the phone’s limited memory and their execution times needed to be short enough to give reasonable turn-around. Finally, we were only interested in establishing the power con-sumption of CPU and memory, rather than making com-parisons between different platforms’ algorithms, hence completeness of the suite was not a relevant considera-tion. From the candidates remaining according to the above criteria, we selected a set representing a good spectrum ofCPUandmemoryutilisation,fromhighlyCPU-bound to highly memory-bound. We determined memory-boundedness by running the entire suite on a server Linux system and comparing the slowdown due to fre-quency scaling. Snowdon et al. [9] show that this slow-down is primarily due to memory-boundedness. While For each of the benchmarks, we measured the aver-age CPU and RAM power at fixed core frequencies of 100MHz and 400MHz. We also measured power for the system in the idle state. Figure 5 shows these results, averaged over 10 runs. The RSD is less than 3% in all cases. For the idle, equake, vpr and gzip workloads, CPU power dominates RAM power considerably at both frequencies. However, crafty and mcf show that RAM power can exceed CPU power, albeit by a small margin. Table 3 shows the effect of frequency scaling on the performance, as well as combined CPU and RAM power and energy of the benchmarks. The wide range of slow-down factors across the different benchmarks validates our selection of workloads as representing a range of CPU/memory utilisations. Benchmark Performance Power Energy equake 26% 36% 135% vpr 31% 40% 125% gzip 38% 43% 112% crafty 63% 62% 100% mcf 74% 69% 93% idle - 71% - Table 3: SPEC CPU2000 performance, power and en-ergy of 100MHz relative to 400MHz. Both CPU and RAM power/energy are included. ... - tailieumienphi.vn