Results for Idle Energy Efficiency
Applies To: Windows 8.1
Idle Energy Efficiency is a workload that can be added to an Energy Efficiency job. An Energy Efficiency job that runs the Idle workload measures the power consumption on a laptop while it is idle, and evaluates the energy consumption and the battery life of the mobile computer. For more information about creating an Energy Efficiency Job and adding the Idle Energy Efficiency workload, see Create and Run an Energy Efficiency Job.
Idle energy efficiency results show metrics and issues that highlight energy efficiency problems. Whenever possible, the cause of the energy efficiency problem is identified. For example, it could be drivers, processes, or services. Recommended solutions for these problems are provided.
This topic helps you interpret the results produced by an Energy Efficiency job that uses the Idle workload. It also provides guidance on how to use the results to identify and resolve common issues that negatively impact system battery life.
In this topic:
About Idle Energy Efficiency
Goals File
Metrics
Issues
For more information about Energy Efficiency jobs, see Energy Efficiency.
About Idle Energy Efficiency
Energy efficiency optimizes the power consumption (Watts hours used) performance across the Windows® base hardware platform, Windows operating system, and extensions. Each of these areas has unique challenges.
Base hardware platform. This includes the processor, chipset, and memory, and for mobile platforms, battery capacity. When buying mobile systems, customers confront considerable choices, which range from systems with ultra-efficient hardware components to systems with components that favor responsiveness over power consumption. The base hardware platform impacts power consumption significantly. Maximum processor speed, the number of cores, processor mobility, and the amount of RAM are all factors.
Windows operating system. Windows manages many of the devices in the system, and makes tradeoffs between responsiveness and power consumption based on use and the active power management policy. The end user dictates power management policy through power plans and settings. The challenges of the operating system are to manage device power properly and to ensure that new Windows features are as efficient as possible in their resource use.
Most users control Windows power management through the power options in Control Panel. They can control a variety of Windows power-saving features, such as inactivity timers that turn off the display. These settings can have significant impact on the battery life of the system. For example, the LCD panel can use up to 43 percent of total system power.
Extensions. Extensions include devices, drivers, services, and applications. Devices, drivers, and other software can have a significant impact on power consumption. For example, a single application can impact battery life by 20 percent or more.Realizing great energy efficiency from a Windows system requires optimization in each area. A problem with any single component in any area can have a significant impact on power consumption.
The Idle Energy Efficiency workload simulates a period of time when the user is not interacting with the system. For example, the system is idle when the user reads a webpage, thinks before typing the second paragraph in a document, or answers a question while giving a power point slide presentation. Reductions in power consumption during the idle state can improve the overall battery life of the system. An idle processor consumes as little as 100-300 mW, a fully active one as much as 35 W. A small amount of activity might lead to a significant increase in power consumption.
Idle power consumption provides the lower bound on power consumption. A system that consumes 10 W while idle, consumes greater than 10 W while running other workloads, therefore, when you reduce the power consumption for the idle period, you might also notice improvements across other scenarios.
An Energy Efficiency job with the Idle workload runs through five phases:
Configuration checks: Disables hibernate and sleep timeout, checks if the kernel debugger is connected, enables driver verifier, and disables wireless network.
Run idle tasks: Defragment the disk to prevent impact on trace collection.
Collect power configuration: Collects data such as USB devices that failed to enter the selective suspend state, and processes, devices, and drivers that issue system availability requests, and so on.
Collect idle trace: Collects the trace for the duration specified in the configuration assessment setting. The default value is 11 minutes.
Process results: Perform energy and power analysis on the idle trace.
Goals File
You can create custom goals to measure your improvements in the Results View. Goals files are a triage tool that can help you understand how a PC is performing and to compare PCs in your business.
For example, goals for a basic laptop might be different than the goals you set for a high end desktop computer, or market expectations might change in such a way that you want the flexibility to define different goals and key requirements as time passes and technology improves.
When a metric value is compared to the goal for that metric, the status is color coded in the Result View as follows:
Light purple means that the system has a great user experience and that there are no perceived problems.
Medium purple means that the user experience is tolerable and you can optimize the system. Review the recommendations and analysis to see what improvements can be made to the system. These can be software changes, configuration changes or hardware changes.
Dark purple means that the system has a poor user experience and that there is significant room for improvements. Review the recommendations and analysis to see the improvements that can be made to the system. These can be software changes, configuration changes or hardware changes. You might have to consider making tradeoffs to deliver a high quality Windows experience.
No color means that there are no goals defined for the metric.
Note
In the Windows Assessment Toolkit for Windows 8, some assessments include default goals files. The first time you view results using this version of the tools, the default goals file is used. However, you can also define custom goals for Windows 8 the same way that you can for Windows 8.1.
You can set the goals file location and add a goals file to that location before you can use the UI to apply the custom goals. Once a goals file is selected it will continue to be the goals file that is used for any results that are opened.
Only one goals file can be used at a time. Goals for all assessments are set in a single goals file. The assessment tools will search for goals in the following order:
A custom goals file
Goals that are defined in the results file
Goals that are defined in the assessment manifest
You can use the sample goals file that is provided at %PROGRAMFILES%\Windows Kits\8.1\Assessment and Deployment Kit\Windows Assessment Toolkit\SDK\Samples\Goals to create your own goals file.
Note
You cannot package a goals file with a job, but you can store it on a share for others to use.
Metrics
Idle energy efficiency metrics originate from two sources: power configuration settings data, and trace analysis data. Each metric, fits into one of the following three categories:
CPU metrics. Metrics related to CPU use, such as C-State residency, periodic CPU activity, and resources used by processes that are active while the system is idle.
Disk metrics. Metrics related to disk use, such as disk read, write, and flush counts, and periodic I/O sources.
Power configurations and other metrics. Metrics such as system timer resolution, the number of USB devices that don’t support selective suspend, and availability request counts.
The following metrics are generated by the idle workload.
System Timer Resolution
Processes that Change System Timer Resolution
Availability Request Count
Power Policy Configuration Errors and Warnings
USB Selective Suspend Issues
C-State Residency (Active and Lowest)
Process Utilization is Greater Than 1 Percent CPU
Periodic CPU Sources Less Than 100ms and Periodic CPU Sources Less Than 300ms
Processes reading > 1 MB
Disk Read Count
Processes Reading > 50 times
Data read from disk (KB)
Disk Flush count
Periodic Disk Sources Less Than 10 minutes
System Timer Resolution
Most applicable to:
This is a primary metric which measures the period of the timer that drives the Windows kernel scheduler. Windows supports a range of timer periods. To extend battery life, the system should configure the lowest frequency possible. The default value for the system timer resolution is 15.6 milliseconds.
Typical Influencing Factors
This metric can be affected by applications that call the timeBeginPeriod function to request that the system increase the frequency of the platform timer. For example, some applications request that the frequency of the timer be increased to drive animations or other high-precision multimedia tasks.
When the system timer period is shortened from the default 15.6 milliseconds to 1 millisecond, the battery drains at least 20 percent faster.
Analysis and Remediation Steps
This assessment inspects the current platform timer period and the maximum timer period that the system supports. The current platform timer period is the duration between successive platform timer interrupts. The maximum timer period is the maximum duration between successive platform timer interrupts (the lowest interrupt frequency) that the hardware can support. The maximum timer period is hardware-specific. For most hardware platforms, the maximum timer period is approximately 15.6 milliseconds (ms).
If the current timer period is less than the maximum timer period, the platform timer interrupt runs at a higher frequency and therefore reduces energy efficiency. In this situation, a warning that contains the current and maximum timer periods is logged in the energy efficiency analysis results. Information about any process that requests a higher timer frequency is also included in the report. The current timer period should always be less than or equal to the maximum timer period.
When there is a change in the default value of the system timer resolution, the assessment identifies an issue for every process that causes the change. From the issue, you can go to the power configuration energy report file. In that file look at the “Platform Timer Resolution” section, search for the process that is causing the issue, and work with the owner of the process.
To maximize energy efficiency, software should increase the platform timer frequency only when it is necessary. For example, a multimedia application increases the platform timer frequency immediately before the application begins a high-precision task. It restores the platform timer frequency to its previous lower frequency immediately after the task completes.
Additional Information
Processes that Change System Timer Resolution
This metric counts the number of processes requesting a system timer frequency change. This metric is related to the System timer resolution metric.
Typical Influencing Factors
This metric can be affected by applications that call the timeBeginPeriod function to request that the system increase the resolution of the platform timer. For example, some applications request that the resolution of the timer be increased to drive animations or other high-precision multimedia tasks.
For more information about analysis and remediation, see System Timer Resolution.
Additional Information
Availability Request Count
An availability request forces Windows to stay awake and prevents the operating system from entering the lowest C-state. The Availability Request metric counts the number of processes making availability requests of any type during idle.
Any availability requests during idle can significantly reduce energy efficiency.
Typical Influencing Factors
The assessment inspects the system and logs any applications, services, or device drivers that make system availability requests, such as requests to prevent the system from automatically turning off the display, prevent the system from sleeping, or enter away mode.
Analysis and Remediation Steps
There are three types of availability requests. Each of these requests can significantly affect energy efficiency. Consider the following:
Display Availability Request. Prevents the display from powering off. If an application requests that the display remain on, for example during a full-screen DVD playback, the availability request should be delayed as long as possible and should be released when viewing is complete. Note that the LCD consumes around 40 percent of the total power.
System Availability Request. Prevents the system from automatically sleeping. For example, an application requests the system to remain on while the application downloads files over a network.
Away Mode Availability Request. Enables away mode. For example, an application requests the system to enable away mode to allow the application to record a TV program at a scheduled time.
Applications and services request system availability by calling the SetThreadExecutionState or PowerCreateRequest functions.
To maximize energy efficiency, applications and services should request system availability only during the time they are processing a task that requires the system to be available.
Additional Information
Power Policy Configuration Errors and Warnings
Two metrics are collected through the Power Policy Configuration of the Windows Power Configuration tool to identify errors and warnings. These metrics identify energy efficiency issues, such as a device or bus that doesn’t have low-power mode support.
Warnings are typically logged when a power policy setting value is out of bounds for power-saving behavior. For example, a warning is logged if the display idle timeout is greater than 15 minutes when the system is plugged in.
Errors are typically logged when a power-saving feature is disabled. For example, an error is logged if the display idle timeout is set to 0 (disabled).
For portable computers, both the Plugged in and On battery values for each power policy setting are inspected. If an energy efficiency problem is detected for both values, separate items are logged in the report, one for the Plugged in value and one for the On battery value. For desktop computers, only the Plugged in values are inspected.
Typical Influencing Factors
Power configuration warnings highlight power settings that are not configured to use low-power modes. These appear in the assessment results. An issue is generated for each power policy warning.
Analysis and Remediation Steps
Click the further analysis link to view the power configuration energy report. In the report, look at the Active Power Plan section, search for the device name that is displayed by the issue, to identify device driver and the root cause affecting the efficiency.
Power policy problems can be resolved by changing the current power policy settings in the Power Options Control Panel or by using PowerCfg from an elevated command window. Note that end users cannot change any power policy settings that are enforced through Group Policy.
USB Selective Suspend Issues
This metric counts the number of USB devices that fail to enter the selective suspend state.
The assessment inspects all USB devices in the system and identifies devices that either do not enter selective suspend or rarely enter the suspend state. An error is logged if a device does not enter selective suspend. A warning is logged if the device rarely enters the suspend state. For every device that is logged as an error or warning, the device name, host controller ID, location, device ID, and port path are included in the results.
When a USB device fails to enter the selective suspend state during idle, it inefficiently consumes power, and possibly prevents the USB device host, the USB hub, and the USB root hub from entering the USB selective suspend state, leading to accelerated battery drain.
Typical Influencing Factors
The USB selective suspend feature lets USB device drivers that support selective suspend turn off the USB devices that they control when those devices are idle. When a device is no longer idle, the system turns on the device and resumes normal operation. When the system is idle and all USB devices are suspended, no processor activity is necessary and therefore the processer can enter a low power state. If any USB device in the system cannot enter the suspended state, the processor cannot enter a low power state even when the system is idle. Battery life on systems like this might be shortened by as much as 25 percent.
Analysis and Remediation Steps
Click the further analysis link to view the power configuration energy report. In the report search for the selective suspend section, search for the device(s) identified by the issue. Note that for every device that is logged as an error or warning, the device name, host controller ID, location, device ID, and port path are included in the report. Once you have identified the driver, ensure that the latest driver is installed.
Consider verifying that USB devices and their drivers support selective suspend. To maximize energy efficiency, consider updating drivers, through the web or Windows Update, to support selective suspend.
C-State Residency (Active and Lowest)
C-states, also known as CPU Idle states, are states when the CPU has reduced or turned off selected functions. Different processors support different numbers of C-states in which various parts of the CPU are turned off. Generally, higher C-states shut off more parts of the CPU, leading to significantly reduced power consumption.
Processor power policy is owned and managed by the Windows kernel power manager. The power manager is responsible for choosing the correct processor state known as the “Target” state. This Target state is based on CPU usage and other factors, depending on the processor power management technology involved. The "Actual" state reflects the actual C-state of the CPU at a point in time.
Note
A CPU manufacturer might choose not to expose all C-states supported by a processor. Time spent in those unexposed states may have been spent in even deeper C-States than indicated. However, if this information is not made available to Windows, information on unexposed CPU states cannot be shown.
The time spent in active C-State measures the percentage of time the processor spends in the most active C-State during idle (C0). The lower the value of this metric during idle, the less power consumed. An issue is generated if the active C-State (%) is greater than 1%.
Time spent in the lowest C-State measures the percentage of time spent in the least active C-State during idle. The higher the value of this metric during idle, the less power consumed. An issue is generated if the active C-State (%) is less the 99%.
Typical Influencing Factors
A high Active C-State Residency during idle results in inefficient power consumption. An issue appears in the job results whenever the Active C-State Residency metric is greater than 1%.
The more time a processor spends in an active C-State, the more power it consumes. The more time a process spends in the lowest C-State, the less power it consumes. A fully active processor can use up to 35 W, while a fully idle processor can use as little as 100-300 mW.
The more frequently a processor switches between C-States, the more power it consumes, and the shorter the battery life.
Analysis and Remediation Steps
Click the WPA further analysis link to open the trace for in-depth analysis. View the CPU idle state graph. Look at the CPU usage (precise) – Utilization by process graph to learn what process causes the CPU to wake up and move into the active C-State.
Additional Information
Process Utilization is Greater Than 1 Percent CPU
This metric counts the number of processes with greater than 1% CPU usage. This metric keeps track of each and every process that uses more than 1% of the CPU during idle.
Typical Influencing Factors
The goal for this metric is 0. CPU use during idle might wake up the CPU frequently. Consequently the CPU switches between C-States, reducing the overall energy efficiency of the system.
Analysis and Remediation Steps
Click the WPA further analysis link to open the trace for in-depth analysis. View the CPU idle state graph, and view the CPU usage (precise) – Utilization by process graph to learn what process causes the CPU to wake up and move into the active C-State.
An issue is generated for every process that uses more than 1 percent CPU time during idle.
Additional Information
Periodic CPU Sources Less Than 100ms and Periodic CPU Sources Less Than 300ms
The PeriodicCPUSourcesLessThan100ms metric counts the number of processes or modules that wake up the CPU more often than once every 100 milliseconds or between 101-300 milliseconds respectively causing a constant fluctuation between C-States. This metric and fluctuation causes one of the most significant impacts on energy efficiency.
A periodic CPU source less than 300 milliseconds might reduce energy efficiency more than a periodic CPU source less than 100 milliseconds if the work per call of the 300 milliseconds call is sufficiently greater than the 100 milliseconds call.
Typical Influencing Factors
Driver, timer, or device interrupts can wake up the CPU often. Frequently recurring CPU activities reduce energy efficiency and shorten battery life.
To maximize energy efficiency, consider eliminating all periodic activities that recur every 100 milliseconds or less.
Analysis and Remediation Steps
For each periodic CPU activity that recurs every 100 milliseconds or less, there is a corresponding driver/timer interrupt issue in the issue section.
Click the WPA further analysis link to open the trace for in-depth analysis. View the DPC CPU usage (Duration by Module, Function) graph.
Suggestions for maximizing energy efficiency:
Consider using a more efficient design instead of high-frequency periodic CPU activity such as polling, spinning, and infinite loops.
Identify opportunities to increase efficiency by searching through your code for calls to SetWaitableTimer(), SetWaitableTimerEx(), KeSetTimerEx(), KeSetCoalescableTimer(), CreateTimerQueueTimer(), CreateThreadpoolTimer() or Sleep(). Idle loops are notorious for this interrupt-driven behavior and a good place to improve efficiency.
Consider converting to a signaled or event driven architecture via SetEvent(), WaitForSingleObject(), or MsgWaitForMultipleObjectsEx() with a large timeout parameter.
Measure periodic CPU activity during idle.
Test in “screen on” and “screen off” scenarios.
Additional Information
Processes reading > 1 MB
This metric counts the number of processes that read more than 1 MB from the disk during idle.
Typical Influencing Factors
Excessive disk activity during idle keeps the disk from powering down, and therefore reduces energy efficiency.
Analysis and Remediation Steps
Click the WPA further analysis link to open the trace for in-depth analysis. View the Disk Usage – Activity by OP type, process, and then select the table and graph view.
Best Practices include the following:
Eliminate disk reads, flushes and writes when the screen is off and the user is not present. Energy efficiency improves when the disk spins down. The disk spins down only in the absence of these types of I/O operations.
Use volatile registry keys to read and write transient data that does not need to be persisted to disk.
Test your application for periodic disk activity. Be sure to test your code in the screen on, screen off, and user not present - screen off cases.
Additional Information
Disk Read Count
This metric counts the number of disk reads issued by all processes. The goal for this metric is 200 reads. The lower the disk read count, the less time the disk spins, the less time the disk heads seek the target track or sector, and the greater the energy efficiency.
Typical Influencing Factors
Disk reads caused by a process or a device driver cause the disk to spin and consume additional power. Issues appear in the results for every process that has a total disk read count exceeding 200.
Analysis and Remediation Steps
Click the WPA further analysis link to open the trace for in-depth analysis. Open the Disk Usage – Activity by OP type, process and then select the table and graph view. For more information about best practices, see Processes reading > 1 MB.
Processes Reading > 50 times
An Idle trace should not have processes which read more than 50 times. Reading more than 50 times from the disk during idle makes the system always active, it also causes the disk spinning for reads. The goal is to have “Zero or 0” processes read more than 50 times.
Typical Influencing Factors
Disk reads caused by a process, a device, or a driver can cause the disk to spin, consuming energy.
A process should not be reading more than 50 time per in every 10 minutes of the trace, and an issue is produced for every process which has a total count of disk reads that exceed the 50 times limit.
Analysis and Remediation Steps
Click the WPA further analysis link to open the trace for in-depth analysis. Open the Disk Usage – Activity by OP type, process, and then select the table and graph view.
For more information about best practices, see Processes reading > 1 MB.
Data read from disk (KB)
Disk read data is a primary counter metric which outputs the total size of all disk-reads in kilobytes, throughout the time of the trace subtracting the first and last 30 seconds.
Typical Influencing Factors
A process should not be reading more than 1 MB of the disk during idle period. The metric reflects the total disk read size of all processes, and an issue for each of the processes that exceeded the 1 MB disk read size.
Analysis and Remediation Steps
Click the WPA further analysis link to open the trace for in-depth analysis. Open the Disk Usage – Activity by OP type, process, and then select the table and graph view.
For more information about best practices, see Processes reading > 1 MB.
Disk Flush count
This metric measures the number of disk flushes to the hard disk. The goal for this metric is not to exceed 200 flushes through the entire trace, subtracting the first and last 30 seconds.
Typical Influencing Factors
Disk flushes can cause the disk to spin, consuming energy. There should be no disk flushes during idle time. The results show a counter metric and an issue for the total number of disk flushes.
Analysis and Remediation Steps
Click the WPA further analysis link to open the trace for in-depth analysis. Open the Disk Usage – Activity by OP type, process, and then select the table and graph view.
Best Practices include the following:
Remove or turn off log-to-disk functionality unless required or specifically enabled or requested by the user, especially when the screen is off. If required, consider logging into a circular memory buffer or use a volatile registry key.
Avoid calls to FlushFileBuffers().
Avoid specifying FILE_FLAG_WRITE_THROUGH as a parameter to CreateFile() calls.
Eliminate disk flushes and write through I/O when the screen is off and user is not present. The disk can be spun-down during this time and any of these types of I/O will cause a spin-up.
Use volatile registry keys for any transient data that does not need to be persisted to disk.
Test your application for periodic disk activity. Be sure to test your code in the screen on, screen off, and user not present - screen off cases.
Additional Information
Periodic Disk Sources Less Than 10 minutes
No process or thread should write to disk frequently enough to spin it up (<10 minutes) and cause subsequent writes to the NTFS log and the master file table (MFT). This excludes writes to MFT and $logfile.
Typical Influencing Factors
Avoid periodic disk activity, for example, logging, timestamps, watchdog-style behavior, and minimize explicit synchronization (such as, write-throughs and flushes). This allows Disk Coalescing to reduce power consumption of the storage subsystem.
There should be no periodic disk I/O during idle time. If there is, it should be longer than the 10 minute interval. The results show any process which issued more than one I/O to the disk during a 10 minute interval.
Analysis and Remediation Steps
Remove or turn off log-to-disk functionality unless required or specifically enabled or requested by the user, especially when the screen is off. If required, consider logging into a circular memory buffer or use a volatile registry key.
Avoid calls to FlushFileBuffers().
Avoid specifying FILE_FLAG_WRITE_THROUGH as a parameter to CreateFile() calls.
Eliminate disk reads, flushes and write through I/O when the screen is off and the user is not present. The disk can be spun-down during this time and any of these types of I/O will cause a spin-up.
Use volatile registry keys for any transient data that does not need to be persisted to disk.
Test your application for periodic disk activity. Be sure to test your code in the screen on, screen off, and user not present - screen off cases.
Additional Information
Issues
The following table describes some known issues caused by inefficient APIs and Frameworks.
| API or Framework | Exhibited Behavior | Alternative APIs and Suggestions |
|---|---|---|
SetTimer() |
Timer does not coalesce. |
SetCoalescableTimer(); follow TolerableDelay parameter guidance. |
WaitForSingleObject, WaitForMultipleObjects, Ex variants (when timeout specified) |
If a short timeout is specified, these APIs can function similarly to a timer that does not coalesce. |
Coalescable versions are not available. Set the timeout parameter for as long as feasible. |
SetWaitableTimer() |
Timer does not coalesce. |
SetWaitableTimerEx(), set the TolerableDelay parameter |
KeSetTimerEx() |
Timer does not coalesce. |
KeSetCoalescableTimer(), set the TolerableDelay parameter |
CreateTimerQueueTimer() |
Timer does not coalesce. |
Convert to SetWaitableTimerEx() or use CreateThreadpoolTimer() and set msWindowLength parameter |
Sleep() |
Timer does not coalesce. |
Avoid writing idle loops based on sleep. Convert to event driven implementation. |
CreateFile() with FILE_FLAG_WRITE_THROUGH |
Forces disk spin-up by write-through writes. |
No alternative – remove flag and avoid explicit synchronization when possible |
FlushFileBuffers() |
Forces disk spin-up by flushes. |
No alternative – avoid explicit synchronization when possible |
CreateFileTransacted() |
Generally expensive, forces files to disk by flushes. |
No alternative – avoid explicit synchronization altogether. |
TimeBeginPeriod() |
Changes system timer resolution. |
No alternative – avoid changing system clock resolution when possible |
See Also
Tasks
Create and Run an Energy Efficiency Job
Concepts
Other Resources
Windows Assessment Toolkit Technical Reference
Windows Assessments Console Step-by-Step Guide
Windows Performance Toolkit Technical Reference