This white paper is one in a series of papers on making software more energy efficient in order to extend PC battery life. In this paper, we describe our wish list for the maximum impact an application should have on battery life, the metrics that should be considered while evaluating idle application impact on battery life, and the Win32 APIs that should be used to decrease the overhead of an application on total platform power.
Battery life is one of the most important factors for mobile platforms. As we move to more optimized hardware especially for Ultrabook™ devices, software (including drivers) plays an increasingly important role in platform energy efficiency. Energy-efficient applications, when idle, should have minimal impact on platform power consumption. In simple terms, applications when idle should consume no additional energy. A single energy-consuming application can thwart all of the power management benefits built into the rest of the system’s software. For example, if an OEM ships a consumer system with one application that has bad power management, the entire system will suffer as it can have a significant impact on the user experience in terms of battery life.
To evaluate software behavior on Ultrabook devices, we measured the battery life impact of an application when running idle on a clean version of a Windows* OS. We used the following hardware and configuration:
- Hardware Components:
- Processor: 2nd generation Intel© Core™ i7 mobile processor
- Memory: 4 GB DDR3 Low Power
- Storage: 160 GB Intel® Solid State Drive
- Intel® Wi-Fi*
- Realtek Audio
- HD 1080p Display
- Software Components:
- Microsoft Windows 8, which includes:
- Intel® Wi-Fi driver
- Intel® HD Graphics driver
- Intel® Chipset driver
- Microsoft Windows 8, which includes:
To get started, we made the following setting changes to a fresh installation of Windows 8 to eliminate certain effects of overhead in the power measurements. We followed the best known method from a Microsoft testing document to remove any background activities while testing .
Figure 1. Battery Life Impact over Clean Windows Idle
An application is idle when it is in a non-active state, for example, a browser application is non-active when a static, simple web page is loaded that does not need user input. Figure 1 shows the results of evaluating the impact these applications had on platform battery life (each application was run individually). Browser-4, for example, decreases the battery life of the total platform by approximately 200 minutes when idle with no user input for a minimum of 30 minutes, while Chat-3 decreases the battery life by ~180 minutes when just running in the background. Combined running of these applications at idle has a significant impact.
Figure 2 shows the comparison of a clean copy of Windows running with no applications installed and all the Figure 1 applications open and running in the background. If a clean copy of Windows idle gives 100% of the battery life, running applications at idle can decrease the battery life by 38.2%. This is a huge impact especially if the applications are idle without any user activity. OEMs that rush to a pre-build software stack must consider their software to ensure it has a minimum impact on consumer PC s’ battery life.
Figure 2. Battery Life Usage Comparison
Table 1. Wish list to develop energy efficient software
Software developers should evaluate the power impact of their software running idle during development. Table 1 gives the wish list or the optimum power an application should use to maximize the battery life on a consumer platform. It shows estimated impact on platform battery life due to software activity on platform. For example, if the platform has a battery capacity of 33 WHr and assuming the platform battery life is 3 W at idle a consumer platform can reach 11 hours of battery life. If there is an increase of just 2% above baseline (i.e., 60 milliwatt increase) over an idle OS, battery life can decrease 13 minutes, while 5% can reduce the battery life by ~30+ minutes. The lower the hardware idle base, the greater the impact applications can have.
A big question for developers is how to measure and reach the optimum amount of an idle application during development. In the next section we will describe how to use the Battery Life Analyzer and Win32 API calls to extend battery life.
Battery Life Analyzer (BLA)
The Battery Life Analyzer (BLA) is a very useful power management analysis tool developed by Intel to identify issues that impact battery life. BLA helps to identify a wide range of issues during software analysis such as:
- Software CPU utilization
- OS timer resolution changes
- Frequent C state transitions
- Excessive ISR/DPC activity
- Graphics vertical blank interrupt updates
Battery Life Analyzer User Interface
The UI for the BLA has several hardware and software analysis modules as shown in Figure 3.
Figure 3. A screenshot showing the user interface for the Battery Life Analyzer program
The steps for collecting BLA data are:
- Select the module
- Modify the module settings, for example, warning thresholds.
- Start the analysis capture
- Stop the capture
- Save the results using the file menu
Developers can also collect BLA data using the command line as shown in Figure 4.
Figure 4. A screenshot showing the Battery Life Analyzer executed from the command line
The BLA command line interface allows for easy integration into your automated test suite. You can run one command at a time or multiple modules sequentially and save the results. Use ”BLA.exe –h” to learn more about usage.
You can collect C-state data to find if your application is having a battery life impact when idle. Compare your results against the expectations in Table 2.
Table 2. C-state Descriptions and Causes
Table 2 shows applications in an idle state must achieve more than 95% of the deepest C-state to get 2% of idle power. Anything less than 95% can cause significant degradation of PC battery life. The table also shows the impact on other C-state package residencies and their causes. For example, an application is performing I/O activities either through internet connectivity, USB devices, or logging information. Software developers should take utmost care by profiling their applications during development for residency states.
We selected a media player application from those listed in Figure 1 to optimize for maximum battery life (i.e., a clean OS installation). We divide this section into two parts based on the two analysis tools we used:
- Windows Performance Analyzer
We profiled the application using BLA for 120 seconds. Figure 5 shows the result of C-state impact of media player software at idle. There is a significant decrease in C7-state package residency when the application is open and idle (i.e., not playing movie/music). The drop in C7-state package residency is due to the increase in C0-C1, C2, and C6-state package residency. The application even when idle was doing CPU activity and network activity, which was causing an increase in package C0 and C2 state residency.
Figure 5. Playback Application C-State Residency
Examining further as to why there is an increase in C0 and C2 state package residencies, we used the BLA tool to find out if any process had an especially significant impact. Table 3 shows the calls/sec activities when the software was running at idle. Process hal.dll, which is associated with OS tick activity, has a huge increase in calls due to a change in timer tick to 1 msec (causing calls 1000/sec) from the OS default of 15.6 msec (64 calls/sec). The change of timer tick rate not only impacts CPU power usage but also has a significant increase in other components such as memory and uncore power. This override of the timer tick rate reduces battery life by 20%.
Table 3. Battery Life Analyzer - Software Analysis
BLA provided good high-level information on software and C-state behavior, which can help developers find issues that cause degradation in battery life during software development.
Analysis of the Video Playback Application using Windows Performance Analyzer
To explore the power impact of individual API calls we used Windows Performance Analyzer (WPA) which is packaged in the Windows Assessment Development Kit.
We profiled playback application in idle state using Windows Performance Recorder (WPR) installed with WPA. We did system-wide collection for 180 seconds and also enabled symbol decoding. Symbol decoding can be turned on from the menu (Trace Tab | Load Symbols) or by adding the following variable to the Windows Environment Variables.
The GUI for WPA provides a very good overview of application behavior. Figure 6 shows the system-wide activity from playback application and system processes. CPU Usage (Sampled) provides an overview of all system-wide processes, call-stack information, and number of operating system context-switches during the selected interval of time. Figure 6 shows Playback application even at idle causes CPU utilization between 0.5% - 2%, and system processes were causing 2% CPU utilization. For an idle application we expect total system CPU utilization to be <1%.
Figure 6. CPU Usage Overtime view in Windows Performance Analyzer
CPU utilization at idle causes an increase in C0-state package residency. We have already seen this media player application had a high C0-state package residency.
To further examine the cause of high CPU utilization, we changed the chart view to timeline view by process/thread in the analysis window as shown in Figure 7. The timeline view gives a better picture of what causes the process to wake up.
Figure 7 shows the view with duration of only 2 seconds. The media player application (labeled blue) has frequent short-duration wakeups and a long burst of wakeups periodically. The system was also causing frequent wakeups even at idle. Performing burst interrupts and letting the system go into deep sleep is good for battery life, but the duration of the time spent doing frequent wakeup needs to be minimized.
Figure 7. WPA View - CPU Usage (Precise)
To find why there is a huge number of wakeups, we analyzed the stack walk for the wakeup events. We drilled down to the cause of application wakeup. Figure 8 shows calls for
WaitForSingleObject every ~2.4 msec causing a ring 0 transition.
Figure 8. WPA View- Call Stack
WaitForSingleObject with a small time out is as damaging to battery life as a call to Sleep with 1 msec. Application thread context switches out after 2.5 msec causing periodic activities due to the timeout specified. The solution is to increase the timeout period to infinite and wait for any job to be called.
Changing the timer tick activity and removing the
WaitForSingleObject had significant improvement on battery life as shown in Table 4.
Table 4. Battery Life Optimization
Timer tick activities can have significant impact on platform power usage (>20% of total platform power usage). Changing timer tick to default saved ~140 minutes of battery life. Changing the Win32 API calls decreased the battery life loss further to just 19 minutes. Still 19 minutes is huge for an idle application, and further optimization is possible. Battery Life Analyzer and Windows Performance Analyzer are two useful tools for understanding your application's power behavior. Test your applications power usage while it is still under development, and look for opportunities to reduce your application’s power consumption while idle.
 Battery Life Analyzer mailto:BatteryLifeAnalyzer@intel.com
 Intel PowerDay video Presentation /en-us/videos/channel/power/extending-idle-application-battery-life/1532766742001
About the Author
Manuj Sabharwal is a software engineer in the Software Solutions Group at Intel Corporation. Manuj has been exploring power enhancement opportunities for idle and active software workloads. He has significant research experience in power efficiency and has delivered tutorials and technical sessions in the industry. He also works on enabling client platforms through software optimization techniques.
*Other names and brands may be claimed as the property of others.
**This sample source code is released under the Intel Sample Source Code License Agreement