Windows On/Off Transitions Solutions Guide-Sleep and Hibernate Transition

Sleep and Hibernate Transitions

Sleep and hibernate are key Windows customerscenarios. Improving performance of these transitions increases convenience andimproves battery life for users. If a sleep or hibernate transitiontakes too long, users may choose to shut down their computers instead
and thereforelose key advantages. For instance, Wake-on-LAN, an extremely useful feature forconserving energy and providing remote access to a computer, is possible onlyif the system is in the sleep or hibernate state. However,sleep and hibernate transitions
have many potential vulnerabilities andchallenges.

During the sleep transition, the systementers a low power state and retains context in main memory.

During the hibernate transition, systemcontext is saved on disk and the system is completely powered down. However,systems with large amounts of RAM might face performance challenges because moreinformation must be stored on disk during suspend and restored
into memory on resume.

Note. The terms “sleep,” “suspend,” and “standby” are sometimes usedinterchangeably. In this paper, “sleep” includes two phases: suspend andresume. In the suspend phase, the system enters a low-power state and in theresume phase, the system
returns to the operational state. In earlier versionsof Windows, “standby” was sometimes used to describe a low-power state in whichin the system was not completely shut down.

Sleep and hibernate transitions aredivided into two high-level phases, namely Suspend and Resume. These arefurther divided into many subphases, each of which is vulnerable to specificperformance problems caused by software inefficiencies, bugs, and configurationissues.

The PostResume subphase is particularlyimportant for performance. Performing minimal activity during this subphase iscritical to providing a high-quality experience when users resume theirsystems. For more information, see “PostResume Subphase” later in
this paper.

This section provides an overview of thesleep and hibernate transitions and describes how to generate and analyzetraces.

Overview of the Suspend Phase

The subphases of the Suspend phase forhibernate and sleep transitions are shown in Figure 14.

Figure 14. Subphases of the Suspend phase for the sleep and hibernatetransitions

Overview of the Resume Phase

The subphases of the Resume phase for thesleep and hibernate transitions are shown in Figures 15 and 16,respectively.

Figure 15. Subphases of the Resume phase of the sleeptransition

Figure 16. Subphases of the Resume phaseof the hibernate transition

Sleepand Hibernate Transitions: Capturing Traces

You can use Xbootmgr to capture tracesof sleep and hibernate transitions. In the following example, the system transitionsto sleep three times and the trace is saved to the traces directory on the rootdrive:

xbootmgr –trace standby –numRuns 3–resultPath %systemdrive%\traces –postBootDelay 120 -traceFlags base

To capture a trace of the hibernatetransition, replace -trace standbywith
‑trace hibernate in the precedingexample.

The following are some key points toremember:

· The Xbootmgr tool does notreboot the test system before the standby tests run.

· The -postBootDelay value specifies the time-out in seconds that thesystem waits after resuming before stopping the trace. The default is 120,which is usually acceptable for suspend/resume testing.

· The -traceFlags base optionprovides a more lightweight and consistent trace from a timing perspective.

· A status dialog box appears duringeach iteration.

· After testing is complete, Xbootmgrcreates the final trace but does not display a dialog box.

Sleep and Hibernate Transitions: Analyzing Traces

You can analyze sleep and hibernatetransition traces by using the Xperf.exe and Xperfview.exe tools in the WPT.Xperf can create Summary.xml files for simplified analysis, and Xperfviewdisplays trace data in graphical form.

To generate an XML summary of theSuspend and Resume phases for either transition, use the
-a suspend action with Xperf, as shown in the following example:

xperf -i trace.etl -o summary.xml -a suspend

Open the Summary.xml file in InternetExplorer. To enable dynamic node expansion, you might need to click the goldInformation bar and then click
Allowblocked content. You should see XML output that resembles that in Figure 17.

In the report, most intervals andoperations are described by start time and duration.

Many phases involve substantial processingby applications, services, and devices. Detailed timing information appears inthe subnode that is associated with each
scenarionode.

Figure 17. The Summary.xml file generatedby using the suspend action in Xperf

The following notes apply to the Summary.xmlfile:

· The scenario node containshigh-levelsummary information.

· duration is the total time for the both the Suspend and Resume phases.

· suspend is the time that is required to suspend the system.

· biosinit is the time that is spent in the BIOs to resume the system. This metricis available only for the sleep transition, not for the hibernate transition.

· resumecritical is the time that is spentperforming actions that are critical to resuming the system, such as resumingdevices.

· resume is the time that the thread that controls the resume transition requiresto finish executing the resume work (sending notifications and so on).

· Hibernate and resumetransitions have hiberwrite and
hiberread attributes.

Currently no attribute corresponds to thePostResumesubphase.

Hybrid sleep, which was introduced inWindows Vista, combines sleep and hibernate. The system enters sleep after itsaves a minimal system context to disk. This allows the system to be restoredeven if an unexpected power failure occurs. Such transitions have
the hiberwrite but not the hiberread attribute.

Sleep and Hibernate Transitions: SuspendAppsSubphase

WhatHappens in SuspendApps

The SuspendApps subphase corresponds to processing the suspendmessage by all windowed applications. During SuspendApps, Windows serially sendsa WM_POWERBROADCAST message with an event type of PBT_APMSUSPEND to allapplications. This message notifies each
application that the system is preparingto suspend and gives it a maximum of 2 seconds to process the message. If theapplication does not complete all its work before this time-out, any remainingprocessing completes after the system resumes from the sleep
state.

SuspendAppsPerformance Vulnerabilities

The SuspendApps subphase is vulnerable to performance issues ifapplications delay processing of the WM_BROADCAST message.

Most applications are not required to do significant work during theSuspend phase. Any such work directly causes a delay in suspending the system becausethe notification process is serial. If several other processes are runningconcurrently on the system
and consuming CPU resources, an application mightnot have sufficient CPU time to complete its work before the 2‑second time-outelapses.

SuspendAppsPerformance Analysis

After you capture the traces and generate the Summary.xml file asdescribed earlier in this paper, open the Summary.xml file in an XML readersuch as Internet Explorer. Detailed per-process timing for the SuspendApps subphaseappears in the
suspendapps node.

The
suspendapps node has thefollowing three attributes:

· start identifies the beginning of thissubphase.

· duration is the entire duration of thissubphase.

· totalChildrenDuration is the sum of durations of allapplications under this node.

The applications are listedin descending order of individual duration. For each application that is listedunder the
suspendapps node:

· start is the time when the applicationreceives the suspend notification.

· duration is the total time that the application takes to process thenotification.

· exe provides the path and name of theapplication.

· pid is the process ID.

In the Summary.xml file, theduration and totalChildrenDuration attributes under the
suspendapps node have different values. The difference in thesevalues (usually 1 second or less) is the time that the video driver requiresto fade out the display and turn off the monitor. In Figure 17, this valueis 1320415 – 472485 = 847930µs
(or approximately 847 ms).

Sleep and Hibernate Transitions: SuspendServicesSubphase

WhatHappens in SuspendServices

The SuspendServices subphase corresponds to processing the suspendnotification by services. Only services that have opted to receive power notificationsreceive this notification, which is serially sent to each service.

SuspendServicesPerformance Vulnerabilities

Most services are not required to complete significant work during thissubphase. However, any work that occurs uses hardware resources, which can delaythe system from entering the sleep state.

Services that are not required to complete any criticalwork during the Suspend phase can choose not to receivesuspend notifications.

SuspendServicesPerformance Analysis

The suspendservices node in the Summary.xml output file includesdetailed per-process timing for this subphase. All services that opted toreceive suspend notifications appear in this node, as Figure 18 shows.

Similar to the suspendappsnode, the suspendservices nodecontains three attributes:
start, duration and totalChildrenDuration. Each service has a start time, duration, andname under the
service subnode.

The duration of this subphase is usually small because services typicallyhave little or no work to do.

Figure 18. The suspendservices node in Summary.xml

In some cases, services can significantly delay sleep by performingnetwork-related activities, writing lots of data to disk, or failing to respondquickly to suspend notifications.

In Figure 18, the service that is named Slowsvc delays system sleepfor about 30 seconds.

To investigate a slow service

1. Note the corresponding start timestamp in the service subnode.

2. Open the trace in Xperfview.

3. In the Services graph,find the container process that hosts the service.

4. In the CPU Schedulinggraph, highlight the region of interest, right-click it, and then choose
Summary Table with Ready Thread.

5. Look for the containerprocess in the summary table. The corresponding wait and ready stacks showwhich stack caused the delay and which stack cleared the wait.

In this example, we found that this service does not respond to thesuspend notification from the SCM and therefore the SCM times out after 30seconds.

Sleep and HibernateTransitions: QueryDevices and SuspendDevices Subphases

WhatHappens in QueryDevices and SuspendDevices

Devices and drivers can significantly affect overall system sleep times.In the QueryDevices subphase, the power manager sends an IRP_MN_QUERY_POWERrequest for the system sleep or hibernation power state so that devices can preparefor the power state change.
The function driver for each device receives this systemIRP and sends a device power query IRP down the device stack.

After all devices have been queried, the system enters theSuspendDevices subphase. Here, the power manager sends an IRP_MN_SET_POWER requestfor a lower system power state. Device drivers must then save appropriatedevice context and prepare the device for
the system to enter sleep or hibernate.

Drivers can delay the suspend transition in both the QueryDevicesand SuspendDevices subphases.

To identify performance problems in these subphases, compare theresults against a baseline measurement.

The Summary.xml output file provides per-driver and per-devicesummaries in the
queryDevices and suspendDevices nodes as shownin Figures 19 and 20.

Figure 19. A snippet of the querydevices node from Summary.xml

The Summary.xml file contains the start and total duration of theQueryDevices subphase as attributes of the
querydevicesnode. Under this node, each device is listed with its name, the start time, andthe total time that was taken to process the query IRP. Figure 19 showsthis information for a USB device. Figure 20 shows the
suspenddevices node.

Figure 20. A snippet of the suspenddevices node from Summary.xml

The structure of the suspenddevicesnode is identical to that of the
querydevicesnode. This node contains information about the time that is required to processthe system set-power IRP.

Sleep and HibernateTransitions: ResumeDevices Subphase

WhatHappens in ResumeDevices

Device and driver performance can have a large effect on the resumetime of the system because all devices must resume before the system canrestore the desktop. During the ResumeDevices subphase, the power manager notifies alldrivers that the system is resuming
by sending an IRP_MN_SET_POWERrequest for S0 toall devices. This subphase is considered complete when all drivers havecompleted the S0 set-power IRP.

ResumeDevicesPerformance Vulnerabilities

Drivers that do not implement fast resume can cause serializationdelays and reduce overall system resume performance. Drivers that use WDF do not require any special codebecause WDF automatically implements fast resume. However, drivers that arebuilt on
the Windows Driver Model (WDM) must follow the steps in “WindowsOn/Off Solutions Transitions Guide” on the WHDC Web site.

Drivers that use excessive CPU resources can also cause delays onresume from sleep or hibernate. Excessively long deferred procedure call (DPC)functions can block lower priority threads from executing or even block otherDPC functions that are queued and
ready to execute. This increases the durationof the device initialization phase and extends the overall system resume time.

ResumeDevicesPerformance Analysis

As with the QueryDevicesand SuspendDevices subphases, you should validate the ResumeDevices data againstthe correct baseline after changes to drivers and devices. The Summary.xmloutput file provides per-driver and device summaries in the
resumedevices node, as shown in Figure 21.

Figure 21. A snippet of the resumedevices node from Summary.xml

Theresumedevices node has start timeand total duration as attributes and contains per-device and driver summariesas subnodes.

Sleep and HibernateTransitions: ResumeServices and ResumeApps Subphases

WhatHappens in ResumeServices and ResumeApps

The ResumeApps and ResumeServices subphases begin immediately afterthe ResumeDevices subphase ends. During the ResumeApps subphase, the kernelpower manager calls into the USER subsystem and requests that it send aWM_POWERBROADCAST window message to all applications.
For services, it calls aprivate interface in the user-mode PnP manager, which then calls each service’spower management event handler.

The ResumeServices and ResumeApps subphases are asynchronous, and thesystem considers them complete after it notifies the infrastructure thatmanages the resume process to resume.

These two subphases are a common source of performance problems. Forexample, consider how much time passed while the system was suspended. Afterthe system resumes, many timers and scheduled tasks can start and manyapplications and services can receive concurrent
notifications. The resultingactivity often leads to high CPU and disk usage, which causes contentionbetween user activity and background resume activity.

For information about how to reduce performance problems that occurduring these subphases, see “Windows On/Off Transitions Solutions Guide” on theWHDC Web site.

Sleep and HibernateTransitions: PostResume Subphase

WhatHappens in PostResume

The PostResumesubphase isa conceptual subphase that covers the time that follows the resume transition. Aswith the boot transition and the PostBoot subphase, the goal is to get thesystem to an idle state as quickly as possible.

The CPU Sampling by CPU and Disk Utilization graphs in Xperfview canprovide insight into how busy the resumed system is, but a valid baselinemeasurement is important when you analyze PostResume activity. Currently, no toolssupport the calculation of a PostResume
metric. Instead, we strongly recommendthat you compare traces from the baseline and the test system to identifyanomalous CPU and disk activity that occurs during the PostResume period.

Sleepand Hibernate Transitions: Summary

The phases of the sleep/hibernatetransitions are complex but important phases to optimize. The following is alist of important things to consider:

ü Use the WPT to measure the performance of drivers, applications, andservices during all on/off transitions.

ü Use WDF to write drivers.

ü Ensure that all drivers implement fast resume and optimize CPUresource usage on resume to achieve better resume performance.

ü Verify that services do not opt to receive suspend notificationsunless absolutely required.

ü Ensure that all applications and services respond quickly to resumeevents and minimize post-resume CPU, disk, and network usage. Performance inthe PostResume subphase is absolutely critical to customer satisfaction.

ü Avoid delays in processing the suspend notification(WM_POWERBROADCAST message) in applications.

ü Optimize resume from hibernate performance by improving BIOS INT13performance.

ü Perform testing in a controlled way, and make comparisons against avalid baseline. Obtain a baseline measurement on a system with as few systemextensions as possible. Add devices, applications, and services one at a time,and test for unacceptable regressions
in on/off transition times.

For details about these recommendations,see “Windows On/Off Transitions Solutions Guide” on the WHDC Web site.