Power Enabling with Windows Vista* on Intel® Laptop Platforms


Abstract

This paper provides an overview of Intel’s laptop platform power consumption on Windows Vista*. It includes recommendations to OEM’s and application developers on how to optimize their software for power efficient mobile experience. The analyses include the new Windows Vista* power management API's, power schemes, case studies and various aspects in energy consumption of the mobile platform components.

Download entire article [PDF 1.5MB]


Executive Summary

Wider adoption on laptops as the primary client systems have put more focus in optimizing for power which will provide longer battery life which then translates to better user experience. Software should be optimized for power in order to complement the hardware in achieving a power efficient platform.  Applications and services have the opportunities to help lower the overall platform power usage by using hardware resources efficiently. The software needs to be designed with platform context awareness that alters the behavior when the power source is DC/battery as compared to when it is on AC power. Enabling for power translates to longer system usabilty for the user.


Background

Client software applications are traditionally optimize for performance in order to provide a better experience for the end user. With the rising popularity of laptops, having power efficient systems and applications for longer battery life is becoming more important. While the hardware components of a mobile platform contributes significantly on the overall power consumption of the platform, software can also contribute either positively or negatively on the total energy consumed by the whole platform.

Windows Vista*, the replacement for Windows XP* has new features including Power API’s and Power policies. Some of the client applications/ new features were profiled on how much power they consumed on Windows Vista*. New programming power API’s which are available in Windows Vista* provide new and easier methods for software developers to access power information.

In order to profile the power consumption of different mobile components, a hardware instrumentation was setup and used NetDAQ* (Network Data Acquisition). In order to measure the instantaneous current/voltage flowing at the target component we tapped into the sense resistors on the reference or engineering board of the mobile platform.

System configuration: Intel® Core™ 2 Duo (Reference Board), Intel® 965GM, 2GB DDR2, 80GB SATA mobile HDD, used NetDAQ* for power instrumentation, Windows Vista* Ultimate 32bit was used on all experiments except for the platform consumption profile graph where Windows XP* Professional was also used for comparison.


Power Policy Settings in Windows Vista*

Windows Vista* provides three default power schemes 1. Power Saver, 2. Balance, 3. High Performance. The Power Saver scheme reduces p erformance by lowering the CPU frequency to minimize power. The Balanced scheme lets the system choose the best power state level (P-state) or CPU frequency based on the overall workload. High Performance provides the maximum CPU frequency or performance regardless of power consumption. Implementation of the maximum performance is different depending on whether the power source is AC or DC (battery). With AC the Processor Frequency state (P-state) stays high (highest frequency) while with DC the frequency starts at low P-state and jumps to high P-state when needed by workload running on the system (referred to as rocket).

The three default power schemes are the “personalities” for all schemes including user created power schemes. The personality indicates the power saving behavior of the scheme. The active power scheme personality can be broadcast to interested components or applications. In Windows Vista* the power schemes can easily be discovered and changed by the users.


Mobile Platform Power Consumption Profile

The graph below shows the power consumption of Windows XP* and Windows Vista* on the Intel mobile reference platform described above using different types of workloads (idle, CPU intensive, and memory intensive). In the idle workload the Windows XP* power consumption is a bit lower than Windows Vista* particularly in some hardware components like HDD, memory, and GMCH (includes Intel® Integrated Graphics). But when you run CPU and memory intensive workloads the OS power consumption is relatively similar between Windows XP* and Windows Vista*. You will notice from the graph that the with both Windows XP* and Windows Vista* CPU has a very wide range of average power consumption from idle ~0.6W to CPU intensive workloads up to ~20W. Other components of the system have relatively narrow range whether they are idle or busy.

The following section goes into discussing various case studies done specifically on Windows Vista* with various applications, new features and new API usages.


Case Studies

This section describes various case studies with applications running on Windows Vista* while exercising new features and new API usages. The case studies were tested to determine how much a particular software application or usage scenario contributes to overall power consumption.

Defragmenter Impact on Power

A heavily fragmented file system can slow down reading and writing of data. While occasional use of the defragmenter is essential to reduce the fragmentation in a file system by placing each file in contiguous space, it also causes significant power consumption as illustrated in the graph below. Various H/W components like the CPU, HDD, memory and chipset average power increases  ~9W average platform power consumtion difference when defragmenting. OEM’s or OSVs can set policies to defer the invocation of the defragmenter when platform is running on battery and resume when AC power source is detected or when a critical battery level is reached.


Virus Scan Impact on Power

This case study starts a virus scan application running while the system is idle. An open source freeware application was used for the study. Some of the components’ average power consumption went up as the graph below indicates, particularly the CPU which climbed to ~ 8.5W. The HDD and memory power consumtion went up a bit but not as significant as the CPU. Developers can set a policy to defer scheduled virus scan runs, e.g. when system is running on battery and no network connection is available or when critical battery level is reach and there is no network connection. The virus scan application needs to scale its behavior based on system context to provide a richer user experience and longer battery life.


Screen Saver Impact on Power

Screen savers are commonly used for desktop/laptop users. While a screen saver hides the system display, it comes with a power cost. We tested the Windows Vista* photo screen saver to determine how much power it consumes. The screen saver does have an impact on overall CPU and platform power with ~1W instanteneous power. While 1W does not seem high, the overall platform energy consumption will be significant if left running for a longer period. A context-aware screen saver can prompt the user when a critical battery threshold is reached.

Windows Vista* Asynchronus Power Notification APIs

Usually applications handle common power management events such as AC/DC power source changes, power scheme changes, monitor on/off etc in oder to react as needed. Applications do this tracking to change the behavior dynamically so user can get expected behavior. For exmple, an application may inform the user that the system is running low on battery, so deferring the task at hand would be better.

Historically in order to track such system changes, applications needed to poll for the data constantly, e.g. GetSystemPowerStatus() API for AC line status to determine if the system is running on AC power or battery. Polling for such changes within the application can sometimes be too much intrusive.

With Windows Vista*, Microsoft* has introduced asynchronus power notification APIs to track these changes. The application can use RegisterPowerSettingNotification() with the appropriate GUID to tack changes.


The graph above indicates the instantaneous Platform and CPU power for tracking AC<->DC (Battery) power source changes. The blue bars represent platform power corresponding to left side Y axis, whereas the line represents CPU power correspnding to right side Y axis. The first 3 data sets show power data with various polling intervals using traditional polling APIs. As the graph indicates when polling interval becomes smaller, there is a bit of increase in power consumption. The last data set (on the far right) represents power using the new asynchronus API. The lower power measurements indicate that these APIs are less intrusive than polling at higher rate (20ms).

Impact of Processor Frequency States (P-states)

P-states are a CPU mechanism to save power when the sy stem is active. Intel® SpeedStep™ technology provides a way for the processor to change the operating frequency if the CPU is not fully used. For example, if the CPU is 50% utilized, in Balance mode, the CPU frequency will be reduced to perform the job efficiently. This helps save power at package level. P-states are inter-dependent can cannot be controlled at core level.

Lowering P-states is good for power savings, but what about applications that use full CPU resources and are well multi-threaded?  In order to test if it makes sense for lowering P-states for such applications (i.e. we make them run longer using lower CPU resources), we took a gaming kernel (physics) and multi-threaded it to have both threads perform same work and consume full (100%) CPU resources.


As indicated in the graph, running the physics kernel at lower frequency shows some reduction in CPU power (red bar), but overall platform power (blue bars) increases. This is because now the kernel takes longer to finish the job at hand and all components of the syetem stay active for longer duration, hence platform power increases. For time-bound applications, where we have a fixed amount of data to process and the application is well multi-threaded using full CPU resources, it is better to finish faster and then go into idle in order to save power. Of course, the recommendation is to allow Intel® SpeedStep™ technology and the OS to determine the ideal CPU frequency for your application. Changing frequency from within the application is not recommended.

LCD Panel Brightness Study

Many game developers provide brightness setting inside their game options (in video settings). They have slider bars where user can select the required brightness level. The intent of this is mainly when user runs the system on battery; they can reduce the display brightness and extend battery life. Game developers commonly use SetGammaRamp() API (or similar) to achieve this purpose. Our tests indicated that this API has no impact on actual LCD or platform power. On our reference board system where an OEM display stack is not installed, we observed that Windows Vista* offers a registry GUID control to access brightness properties. But when OEM stacks are installed, in most cases, this GUID is not available.

Windows Vista* offers APIs to access these registry GUIDs. When some of the OEM systems are used, we see that the ‘Display Brightness Setting’ GUID is disabled so the developer has no way to access the actual brightness settings registry key from within the software.

So the main issue that needs investigation is

  • Is it possible to enable the ‘Display Brightness Setting’ GUID after OEM display stack is installed on the laptop?

 

If so, software developers could exercise better control over battery life when implementing features to control display brightness.

The data below demonstrates this.


This data was collected for a very popular first person shooter game with 14” panel size. CPU and Platform power correlate to major Y axis (on left), while the red line which is pane l power correlates to minor Y axis (on right). The first data set indicates the game running with default options as provided by game developer. The second data set indicates when we set the brightness control offered by the game to most bright. The third data set indicates when we set brightness control in the game to least bright. As shown in data sets 2 and 3, changing game brightness doesn’t have any impact on the power consumption. An average user may not realize it but effectively there is no battery life saving with use of brightness control in the game. This is misleading to users as they would expect reduction in power consumption with less brighter setting in the game.

Data sets 4 and 5 indicate when we used the ‘display brightness setting’ GUID from Vista on non-OEM system which clearly shows reduced power on panel as well as platform.

Our recommendation here is to have a unified way to access brightness control from within an application across multiple OEM systems. We see two possible alternatives:

  1. Enable the ‘Display Brightness Setting’ GUID inside ‘Display Setting’ Subgroup after OEM stacks are installed. (Currently this GUID is disabled on the OEM system)
  2. OEMs/IHVs implement WmiMonitorBrightnessMethods class (recommended by Microsoft*), so developers can implement using this class and effectively change LCD brightness

 

We are discussing these alternatives with OEMs to get their feedback.


Summary

  1. Design and test applications with power management in mind. Alter application behavior dynamically in order to get the best user experience.
  2. Windows Vista* offers an asynchronus way to get notification for platform status changes such as AC<->DC transitions. These APIs are more power efficient than polling frequently. Utilize these new APIs in order to get best power benefits.
  3. Let Intel® SpeedStep™ technology and the OS determine the best suitable operating frequency for your application. If the application is well threaded and utilizing all available cores to full resources, then finishing the job faster and then going into an idle state might be better for overall platform power.
  4. Lower granularity timers/polling loops are better from a system power consumption perspective. Frequent polling prevents the processor from entering deeper sleep states which in turn affects overall platform power.
  5. Make Virus Scanning softwares, and utilities such as defragmentors aware of the system power source and it’s status so that the behavior can be changed dynamically in order to save power and deliver the best possible user experience.

 


References

 


About the Authors

Rajshree Chabukswar and Jun De Vega are Software Engineers from Intel’s Software & Solutions Group working on power and performance optimizations with 3rd party software developers.


For more complete information about compiler optimizations, see our Optimization Notice.