A Simplistic Way for Power Profiling of Mobile Devices

Grace Metri*, Abhishek Agrawal*, Ramesh Peri*, Monica Brockmeyer, and Weisong Shi
Department of Computer Science, Wayne State University, Detroit, Michigan * Software Services Group, Intel Corporation, Santa Clara, California gmetri@wayne.edu, {abhishek.r.agrawal, ramesh.v.peri}@intel.com, {mbrockmeyer, weisong}@wayne.edu
AbstractSmartphones and tablets are enabling people to perform day to day tasks which were previously impossible to perform without a personal computer. Smartphones and tablets are, by nature, highly dependent on battery life. As a result, a major challenge faced by developers is to understand how their software impact power usage of a device because users of applications tend to evaluate an application not just by its utility and performance but by its impact on battery drainage as well. As a result, developers need to debug the energy efficiency of their applications alongside debugging their performance. In this paper, we explain the power profiling techniques used to determine energy efficiency of applications on Android devices. We also introduce our Software Power Monitor (SoftPowerMon) tool which can aid developers debug applications from an energy perspective and can even help platform developers develop more efficient systems. Then, using SoftPowerMon, we power profile three different devices: two smartphones and a tablet. We conclude by comparing the performance overhead of our tool to other tools and we show that SoftPowerMon can answer why a specific amount of power is consumed on a device as opposed to how much power is consumed. Keywords power profiling, smartphones, Android, tablets, energy efficiency.

efficiency of these devices is at the forefront of research topics related to mobile devices. Needless to say, the competition in this field is very high. There are several operating systems in the market such as Googles Android which is currently the most popular OS, Apples iOS, and Windows Mobile. The competition is not restricted to the platform but it is also extended to the market of mobile applications. Since energy efficiency is one key evaluation component, it becomes necessary for platform developers and application developers to power profile their platforms and/or applications. It is not enough to simply understand how much power a device is consuming or to predict how much it might consume, but there should be a deeper focus on understanding why a specific amount of power is consumed. In this paper, we propose a methodology for measuring power consumption behavior of Android applications using a Software Power Monitor tool (SoftPowerMon). The intent of this tool is to provide platform and software developers a mean through which they can examine how their platform and/or Android applications can affect the battery life of devices The remaining paper is organized as follows: we compare some related work in Section 2. In Section 3, we list and explain power profiling techniques used in order to determine the energy efficiency of applications on Android devices. Then, Section 4 introduces Software Power Monitor tool and we present case studies in Section 5. In Section 6, we provide an overhead analysis of SoftPowerMon and then we conclude in Section7. II. RELATED WORK

I.

INTRODUCTION

The use of smartphones and tablets is continuously on the rise. It is forecasted that by 2015, the sales of these handheld devices will surpass the sales of Notebook Personal Computers [13]. There are many reasons for the popularity of these devices. First of all, there are thousands of applications developed specifically for these handheld (mobile) devices such as games, maps, video players, reminders, and so on. Having thousands of these applications makes it easy for clients to rely on their devices to perform tasks that would have required a computer in the past. Second, the size of smartphones and tablets makes them portable and easy to carry. Third, Internet and data networks have become very accessible either through 3G networks or through Wi-Fi. Smartphones and tablets are highly dependent on their battery life. What is the point of having a very powerful device with a short battery life? As a result, clients nowadays evaluate and compare devices and applications based on their performance and energy efficiency. Therefore, the energy

There are many research related to the battery life of smartphones and tablets. Zhang et al. [2-3] introduced PowerTutor which is a power monitoring application for Android users in order to monitor the behavior of applications on their devices. It can also provide power estimation of applications. A. Pathak et al. [14] implemented eprof in order to optimize an applications energy efficiency through a system-call-based power modeling approach for online power estimation for Android mobile and Windows phone. Most of this research focuses on power modeling and battery life estimation whereas we focus on understanding the

978-1-4673-5328-1/12/$31.002012 IEEE

impact of an application on the underlying platform. We developed a tool which allows micro profiling of CPU power consumption in order to give data to platform developers and application developers on the impact of their platform and/or application on the power consumption of the device. We focus on giving information on why a specific amount of power is consumed as opposed to how much. III. POWER PROFILING TECHNIQUES USED TO DETERMINE ENERGY EFFICIENCY OF APPLICATIONS ON ANDROID DEVICES Android is an open-source project published by Google Inc. since 2005. Android mobile operating system is developed based on a modified Linux 2.6 Kernel. It uses native Linux libraries to manage and set policies of the Linux Power Manager. Conserving energy can be achieved by shutting down unused components during idle time, changing the power performance states of the CPU based on the device load, and reducing/eliminating the unnecessary wakeups of the system. A. Processor Idle Sleep States: Modern processors attempt to reduce their power consumption by supporting different idle states known as Cstates. The power savings is achieved by turning off the unused architecture blocks of the CPU. The C-states supported by a CPU are dependent on the type of CPU. Regardless of the CPU type, the deeper the idle state, the greater the power savings and the more components in the CPU are switched off [1]. On the other hand, the deeper the idle state, the longer it takes for the processor to move from that idle state to an active state. There are two types of idle states: core idle states and package level idle states. In multi core devices, each core can have its own independent idle state. However, regarding the package idle states, a package cannot enter deeper idle states unless all the cores in the system agreed to enter the same level of idle state or a deeper one. The energy efficiency of an application can be measured by the percentage of time it allows the processor to enter an idle state. Linux kernel gives us enough information to be able to determine the processor states. The kernel keeps track of all the idle states supported by each processor, the idle states corresponding name and description, its exit latency in microseconds, time spent in that state in microseconds, and power consumed in milliwatts. All this information can be found under /sys/devices/system/cpu/cpuXX/cpuidle where XX represents the CPU number. Finally the time spent in active state for each CPU can be determine based on the CPUs time in idle state and test duration. B. Power Performance States: Power performance states known as P-states are the processors frequency and/or voltage. This number of frequency states is depended on the processor type. The processor can change its frequency and /or voltage based on the workload as a mean to save power. The slower the processors frequency, the less its power consumption and vice versa. The Linux kernel can have different policies for the processors frequency known as governor. There are several

governors and the processors can support one or more governors. Typically, the governor is set to be based on the load where the load increases, the CPU increases its frequency or reduces it otherwise. Governors can also be set to powersave where the lowest frequency is selected at all time or it can be set to performance where the highest frequency is set at all time. A user may set the frequency by accessing the following directory /sys/devices/system/cpu/cpu0/cpufreq/. For power profiling, we are interested in knowing the time spent in each frequency. This information is available at /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state. This information will allow us to determine the pattern of power consumption of the CPU when it was in active state. C. Dynatick (Tickless Operations) Traditionally, the Linux kernel used a global timer for time keeping purposes. This timer also known as timer tick causes timed interrupts. Since these interrupts dont take into consideration the idle state of the CPU, they will cause the CPU to switch to active state in case it was idle during the timer event. The kernel has long moved from timer tick mode to dynamic tick Dynatick mode instead where timer interrupts occur only when needed [11]. These ticks are particularly important for power management of a platform because they can have a direct impact on the duration the CPU can remain in idle residency state. By accessing /proc/timer_stats, the system reports the dynatics in addition to total number of events along with the average events per second. This information is particularly important for the kernel, operating system, and platform developers. D. System Interrupts Linux Kernel also keeps track of the resources which woke the system up. It keeps track of the number of interrupts per CPU. It detects and records the internal interrupts such as the nonmaskabe interrupts (NMI), local timer interrupts (LOC), TLB flush interrupts (TLB), rescheduling interrupts (RES) and remote function call interrupts (CAL). It also records the external interrupts for I/O devices. The system interrupt data can be collected from /proc/interrupts. The fewer number of interrupts results in fewer wakeups leading to less power to be consumed. IV. SOFTWARE POWER MONITOR TOOL (SOFTPOWERMON) We developed a power analysis tool using Python which can be used by any Android platform in order to perform debugging of the energy efficiency of Android applications with negligible overhead. SoftPowerMon requires that Android Debug Bridge (adb) [12] be installed on a host computer. The tool runs on the host computer and can access the platform under testing using a USB connection. There is a special version of Power Performance States test which allows profiling without consistent USB connection. Only rooted devices may be profiled. Finally, the tool provides an output file containing all the raw data collected in addition to postprocessing data. Processor Idle Sleep States Test: using SoftPowerMon, we were able to collect the time spent

in each idle sleep state for each core. In addition, we were able to collect the usage value for each of the idle states. This usage value represents the number of transitions to a specific idle state. In our implementation, we took into consideration the fact that some types of processors are capable of turning one or more cores offline during the test duration. As a result, we continuously extracted the list of online cores. Finally, during the period of post processing, we calculate the percentage of time the core spent offline, the percentage of time spent in each idle state, and the percentage of time spent in active state. Power Performance States Test: In order to determine the time spent in each frequency, we collect the P-States time_in_state for each frequency at the beginning of the test and then collect the same values upon the end of the test. The difference between the end values and the beginning values represent the time spent in each frequency. Online Test: For the online test, we continuously extract the list of online cores from the system along with the timestamp. Dynamic Tick Events Test: In order to collect the dynamic tick events, we simply prompt the system to collect those data during a specific period of time. Then we extract that information to the tool user. Other Tests: We also created a test for collecting system interrupts and another test to collect some statistics about the system such as the number of cores, the available idle sleep states with their corresponding wakeup latency, and the power performance states supported along with statistical information such as the maximum and minimum power performance states

TABLE 1: BENCHMARKS DESCRIPTION Benchmark Description It contains pure JavaScript benchmarks for OS kernel simulation, one-way constraint solver, Encryption and decryption, classic Scheme, and regular expression benchmark [7] It is an independent graphics benchmark made to test the performance of embedded GPU systems. It uses the industry standard OpenGL|ES 2.0 API to push GPUs to their limit in a setup that resembles that of a game. [8] Browser JavaScript benchmark workload used to cross browser to test JavaScript performance [9] It is a performance testing utility measures different graphic and computation capabilities of a mobile devise. The tests focus on graphic resources, measuring the quality and performance of the underlying OpenGL ES 2.x implementation. The benchmark contains high-level 3D animation [10] Played Elephant Dreams movie Screen on and nothing running on the background

Google V8

NenaMark2

Sunspider

GL

YouTube Idle

The power modes of this processor are as follows [4]: - ARM Clock gating (WFI) is state0 idle state where most of the clocks of the processor are disabled while its logic is still powered up. The exit latency is 1us. ARM Power Down is a semi-idle corresponding to state1 where the processor is powered down while the caches remain powered up and maintaining their state. The exit latency is 300 us.

The second device used is a rooted Samsung Galaxy Nexus 3 running Android 4.1.1 Ice Cream Sandwich. The device features an ARM dual core 1.2 GHz Cortex-A9. The power modes of this processor are as follows: - C1 (WFI) is mapped to state0. It is similar to the WFI state explained for Samsung S3. Its exit latency is 4 us. C2 (CPUs OFF, MPU + CORE INA) is state1 where the CPU is off, Memory Protection Unit (MPU) is on in order to protect critical data, and the core is inactive. The exit latency for this state is 1100 us. C3 (CPUs OFF, MPU + CORE CSWR) is state2 and similar to state1 with the exception that the core is in Closed Switched with Retention mode. The exit latency for this state is 1200 us. C4 (CPUs OFF, MPU CSWR + CORE OSWR) is state3 similar to state1 with the exception that the core is in Open Switched Retention mode. The exit latency is 1500 us.

The combination of all these data can give a clear view about the energy efficiency of a platform or application and keeps the focus from how much power is consumed to why this much power is consumed. V. CASE STUDIES We performed two case studies. The first case study used two smartphones: a Samsung S3 and a Samsung Galaxy Nexus 3. The second case study used Motorola XOOM tablet. For all the devices, we ran the Android benchmarks as listed in table 1. We collected the power performance and idle sleep states in addition to the dynamic ticks. A. Smartphones: Samsung S3 and Samsung Galaxy Nexus 3 The first smartphone device used is a rooted Samsung S3 smartphone device, model number GT-19300 running Android version 4.0.4 Ice Cream Sandwich with Linux Kernel 3.0.15. The smartphone features Exynox Quad core (Exynox 4412) also known as Quad ARM Cortex-A9 core. This type of processor is capable of turning one or more cores offline.

We collected the idle states and power performance states on both devices for our entire list of benchmarks. Figure 1 displays the data collected for Samsung S3 Idle states residency values. By examining the graph, you will notice that for few benchmarks, the data collected do not add up to a 100 percent. During those cases, the core was neither in Active state nor in WFI state but offline instead.

Figure 1 also shows that core1 remained for over 80 percent in active state whereas core2 was offline during Google V8 benchmark. These results show that Google V8 does not run efficiently on the device because despite trying to save power by switching the status of Core2 to offline, Core1 remained in Active state for the majority of the time and thus preventing the platform to go into low package idle state. The idle states of Nexus are displayed in figure 2. Google V8 behaved similarly as its behavior on S3. Even though core1 was not turned offline, there were no idle states balance between core0 and core1 (Note: Switching cores to offline modes is not supported by Nexus). Figure 2 also reveals that Sunspider benchmark had a higher percentage of active states compared to the other benchmark. Figure 3 displays the number of idle states transitions to WFI per second for Samsung S3 and Nexus. By comparing S3 and Nexus, it is clear that the number of transitions for S3 is much higher than Nexus. This information is helpful for platform developers because an overhead is incurred when the processor keeps switching states. Therefore, platform developers need to understand whether this continuous switching of states is due to an optimized platform which switches to idle states whenever possible or maybe there are unnecessary interrupts which switches the CPU state from idle to active on a continuous basis leading to a cycle of switching between active and idle. Figure 4 displays the percentage of time spent in each power performance state for Samsung and figure 5 displays the same information but for Nexus. Google V8 power consumption is the most because both phones remained in the maximum power performance frequency during the majority of the test. In addition, there is other information which can be used by platform developers such as the power performance states of S3 during idle scenario compared to Nexus. S3 stayed for 17.57 percent of the time in a power performance state higher than its minimum frequency whereas Nexus spent only 3.7 percent. This gap needs to be reduced in order to increase S3s energy efficiency. We also collected the number of dynamic ticks per second for Samsung S3. Typically, these dynamic ticks information are not necessary to collect for application developers but can be useful for platform developers.
Figure 3. Comparing number of idle states transitions to WFI per second for Samsung S3 and Nexus 3.

Figure 2. Comparing percentage of time in idle states residency for Nexus 3.

Figure 4. Comparing percentage of time in power performace states residency for Samsung S3

Figure 1. Comparing percentage of time in idle states residency for Samsung S3

Figure 5. Comparing percentage of time in power performace states residency for Nexus 3.

TABLE 2: BENCHMARKS DYNTICKS EVENTS PER SECOND ON SAMSUNG S3 Benchmark V8 NenaMark2 GL Sunspider Dynticks Events Per Second 712.902 502.227 546.378 767.662

B. Tablet: Motorola XOOM The device used is a rooted Motorola XOOM tablet running Android 4.1.1 Ice Cream Sandwich with Linux Kernel 2.6.39.4. The XOOM tablet features a NVIDIA Tegra 2 SoC integrated with dual core ARM Cortex-A9. This processor offers two idle state modes: CPU Flow Controlled mode (LP3) is state0 idle state and is characterized by having the CPU turn off all the components except the memory units. The exit latency of this state is 10 us. CPU Power Gate (LP2) is state1 idle state and is characterized by a complete shutdown. The exit latency of this state is 1500 us.

Figure 6. Percentage of time in idle states residency for Motorola XOOM

For this case study, we followed the same testing methodology as we did for the smartphones. Figure 6 displays the data collected for the percentage of time spent in idle states residency for the tablet. It is evident that both cores remained in higher percentage of active states while we were running YouTube. We also observed that core 0 remained active for longer period of time compared to core 1 for all the test scenarios. This explains the reason behind core 0 higher numbers of transitions from active state to idle states compared to core 1 as displayed in Figure 7. Some other important facts were observed for Google V8 and Sunspider benchmarks. We noticed that for both benchmarks, the utilization of the cores was not balanced. There is a significant gap between active state duration among both cores. This imbalance can negatively impact the percentage of time spent in package level idle state residency. Since the package can only enter idle states when both cores are idle, then this imbalance leads to longer duration of package active state. This fact consequently explains the data collected for P-states as shown in figure 8 where the CPU remained in the max CPU frequency for the majority of the time while running the two discussed benchmarks. Unlike Google V8 and Sunspider, Nenamark2 and GL benchmarks had balanced percentage of time in active state between core 0 and core 1. In addition, the CPU spent only around 50 percent of the time in the max frequency and between 31 and 24 percent of the time in the min frequency. Finally, we showed how by using SoftPowerMon, we gained insight on the power behavior of the benchmarks at the micro level without the need of any sophisticated tool. We also showed that across the devices, the benchmarks had similar behaviors patterns. This is an important characteristic since it allows the application developers to only test their application on a small subset of devices.

Figure 7. Comparing number of transitions to idle states per second for Motorola XOOM

Figure 8. Comparing percentage of time in power perfromance states for Motorola Xoom

VI.

PERFORMANCE ANALYSIS OF SOFTPOWERMON

One main goal of our SoftPowerMon tool is to be able to collect power consumption behavior of Android applications with low overhead. We compared our tool to similar tools for profiling power consumption of Android Applications. The first tool we examined is PowerTutor [2] which provides information such as energy usage over time of different phone components such as LCD, Wi-Fi, CPU and 3G. The second tool we examined is System Panel App / Task Manager Pro [5] which displays CPU, memory, and network activities in addition to battery usage of the device. In order to evaluate the performance overhead of our tool, we randomly selected NenaMark2 from our list of benchmarks. We collected the data using SoftPowerMon on Samsung S3 while following three different scenarios: (1) running the benchmark alone (2) running the benchmark along with running PowerTutor in the background (3) running the benchmark along with System App/Task manager Pro running

in the background. Figure 9 represents the results of idle states residency percentages collected during the three scenarios where SPMon, Ptutor, and SysPan are associated with scenario 1, 2, and 3 respectively. Based on the results, it is evident that using SoftPowerMon without any other profiling tool, the device remained in active states for shorter percentage of time when compared to running it while other profiling tools were collecting data. Table 3 represents the performance states residency results for the same above scenarios. By comparing the results, we noticed that by sole using SoftPowerMon, the device was able to run during 5.96 percent of the time in the low P-state frequency of 500 MHz whereas it spent 0 percent of time in the same frequency during the other two scenarios. In addition, by sole using SoftPowerMon, the device remained around 6 percent less time in the high P-state frequency of 1200MHz when compared to the other two scenarios. Another strategy to evaluate the overhead of collecting data via SoftPowerMon was to observe the impact of SoftPowerMon on the power and CPU utilization data collected using PowerTutor and SystemPanel. We noticed that there were no variations in the data collected via the latter two tools when we compared the results obtained while running SoftPowerMon and without running it. Finally, PowerTutor and SystemPanel are capable of collecting more information than SoftPowerMon. However, if a users intent is to just collect the impact of an application on the power utilization of the CPU and look at its direct impact on the idle state residency and power frequency, then SoftPowerMon is the best choice. It can provide all these data to the use with minimal overhead. Knowing the percentage of CPU active state and its frequency can give micro level perspective on why an application is consuming a specific amount of power.

VII.

CONCLUSION

In this paper, we list and explain available debugging techniques for energy efficiency of applications on Android devices. We developed SoftPowerMon, a tool which can be used by developers in order to debug the energy efficiency of their Android applications with very low overhead. Then, we presented two case studies where we collected and analyzed energy data using SoftPowerMon on two different devices for several Android benchmarks. Finally, we compared the performance of SoftPowerMon to two other popular profiling tools and determine that it can collect data with negligible incurred overhead. SoftPowerMon can explain why an application is consuming a specific amount of power as opposed to how much it is consuming. REFERENCES
[1] A. Agrawal, T. Huff, S. Potluri, W. Cheung, A. Thakur, J. Holland, H. Jiang, V. Degalahal. Power Efficient Multimedia Playback On Mobile Platforms, Intel Technology Journal, Volume 15, Issue 2, 2011. Z. Yang, PowerTutor A Power Monitor for Android-Based Mobile Platforms EECS, University of Michigan, retrieved September 2, 2012. Available: http://ziyang.eecs.umich.edu/projects/powertutor/ L. Zhang, B. Tiwana, Z. Qian, Z. Wang, R. Dick, Z. M. Mao, L. Yang. Accurate Online Power Estimation and Automatic Battery Behavior Based Power Model Generation for Smartphones, in Proceedings of the eighth IEEE/ACM/IFIP international conference on Hardware/software codesign and system synthesis (CODES/ISSS 10), 2010. ARM Info Center, Cortex A-9 Technical Reference Manual, retrieved August 19, 2012. Available: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0388i/DDI0388I_c ortex_a9_r4p1_trm.pdf System Panel APP / Task Manager Pro. http://android.nextapp.com/site/systempanel. Retrieved: September 24, 2012. Motorola Xoom Specifications Table, Motorola Developer, retrieved September 20, 2012. Available: http://developer.motorola.com/products/xoom-mz601/ Google V8 benchmark suite, retrieved August 5, 2012. Available: http://v8.googlecode.com/svn/data/benchmarks/v5/run.html NenaMark2, Nena Innovation AB, retrieved August 5, 2012. Available: http://nena.se/nenamark/view?version=2 SunSpider JavaScript Benchmark, retrieved August 5, 2012. Available: http://www.webkit.org/perf/sunspider/sunspider.html GLBenchmark, Kishonti Informatics. Available: http://www.glbenchmark.com/index.jsp S. Siddha, V. Pallipadi, A. V. D. Ben. Getting maximum mileage out of tickless, Linux Symposium, 2007. Android Debug Bridge, Android developers, retrieved June 25, 2012. Available: http://developer.android.com/tools/help/adb.html Worldwide Smartphone markets: 2011 to 2015, Research and Markets, retrieved August 25, 2012. Available: http://www.researchandmarkets.com/research/7a1189/worldwide_smart pho A. Pathak, Y. C. Hu, M. Zhang, P. Bahl, and Y. M. Wang. FineGrained Power Modeling for Smartphones Using System Call Tracing, presented at the Proceedings of the sixth conference on Computer systems (EuroSys 11), 2011.

[2]

[3]

[4]

[5]

[6]

[7] [8] [9] [10] [11] [12] Figure 9. Comparing percentage in C-States when running SoftPowerMon, PowerTutor, and SystemPanelPro during NenaMark2 benchmark. TABLE 2: COMPARING PERCENTAGE IN P-STATES DURING NENAMARK2 BENCHMARK. Frequency 1400 MHz 1200 MHz 1100 MHz 700 MHz 500 MHz SoftPowerMon 0.20 93.71 0.06 0.05 5.96 PowerTutor 0.27 99.73 0 0 0 SystemPanelPro 0.64 99.36 0 0 0 [13]

[14]