Challenge

Enable power-event interception and control under Microsoft Windows XP for mobilized applications. From the very first 4.77 MHz 8088 Intel processor to today’s latest Pentium® 4 processor, an internal system clock running at 14,318,160 Hz has existed. For reasons tied to the original PC system design, this clock is internally divided by 12, yielding a frequency of 1,193,180 Hz. That divided clock is then fed into a 16-bit counter that overflows once every 65,536 counts, effectively dividing the 1,193,180 Hz by 65,536, to result in a frequency of 18.2 Hz. This frequency was available as a hardware interrupt on the original 4.7 MHz 8088 system.

By counting the number of interrupts caused by overflows, 8 bits at a time, from the 16-bit counter/timer, a somewhat accurate hardware counter can be obtained. This is the primary method by which the system clock is read, though it is not without its caveats. One of the existing problems with reading this clock is that you can't read either the interrupt count or the hardware divider at the same time, and when reading the number of interrupts (overflows) you cannot be not sure if they have been read before or after the next one comes in, relative to the count in the 16-bit divider, it is possible to "synthesize" the hardware state into a coherent counter running at 1.193180 MHz. Inverting this gives a timer counter interval of 0.838 microseconds, or 838 nanoseconds. Further, calling the system clock with great frequency is prone to error and inaccurate results because of the longer clock interval.

With the Pentium processor, Intel added an additional instruction called RDTSC (Read Time Stamp Counter). This gives software direct access to the number of clock counts the processor has experienced since its last power-on or hardware reset. With contemporary clock rates of, for example, 3.06 GHz, that results in a timing period of only 0.326 nanoseconds.

The clock rate determined by RDTSC is 100% dependent upon the core frequency of the processor, unlike the older, 1.193180 MHz clock. Because of this, RDTSC varies its counter as the system speed changes when Intel SpeedStep® technology is enabled, making values read by it not consistent.

The Single Processor HAL (Hardware Abstraction Layer) of Windows* 2000/XP uses the same 1.193180 MHz counter for its "QueryPerformanceCounter" API as all previous versions of Windows. However, the Multiprocessor HAL of Windows 2000 and XP use the system's own clock rate through the RDTSC processor instruction. This causes problems for software where performance monitoring is underway and Intel SpeedStep technology is enabled, as the values read from the RDTSC instruction vary with respect to frequency, and hence the timing values read are typically skewed.

Solution

By changing the power usage on a system running Intel SpeedStep technology, such that its implementation is effectively pushed to where no frequency changes occur, the RDTSC instruction becomes reliable from one read to the next and is hence useful for the purposes of code profiling. This can be done simply enough by indirect calls to the Processor Power Scheme API calls ReadProcessorPwrScheme and WriteProcessorPwrScheme. However, the Windows XP operating system does not allow for a method of being interrupted when the power scheme changes.

The method described here utilizes a power-managed driver to notify an event handler in user mode process space. In doing so, the user mode process can defer any power scheme changes to after the profiling session is completed, thus retaining consistency in the profiling metrics.

The method involves first registering a power-managed event callback (DeviceDispatchPower) in a driver running in Kernel Mode. This rou ne responds to all power-managed events in the operating system. In a standard power-managed scenario, this routine is provided to the driver so that it can change the power states on the hardware that it is controlling. Since the driver is filtering power events for the entire system, it provides an easy scheme for filtering these events and preventing deleterious event changes by deferring them off to a time after the profiling session has completed.

The following figure displays this architecture at a high level:

Source

Power Event Interception and Control under Microsoft Windows* XP