Guidelines For Providing Multimedia Timer Support
Updated: September 20, 2002
This article provides information about the requirements for a new system timer that is needed in chipsets to replace legacy timers and to meet the needs of time-sensitive applications. System timers are the timers used by the operating system to perform core tasks such as tracking the time of day and triggering time-based events. This article does not pertain to peripheral timers such as watchdog timers and video card timers.
On This Page
Since the PC was introduced, processor speeds have increased by at least two orders of magnitude and applications have become increasingly sophisticated. This evolution has put new demands on the timing hardware of todays PCs in regard to resolution and performance. Attempts to meet these demands on current systems have forced developers to sacrifice application quality and overall system performance in order to overcome the limitations of todays timing hardware. To provide true support for applications, and to enable more sophisticated applications in the future, system timer hardware must provide at least one-millisecond resolution and aperiodic functionality.
Although one-millisecond resolution and aperiodic functionality are theoretically possible using todays timer hardware, achieving this level of granularity and taking advantage of this functionality while maintaining reasonable system performance is not possible in reality. To make this level of resolution and functionality realistically possible, a new timer is needed that replaces the legacy timers used currently. The new High Precision Event Timer (HPET) was designed to have very fine-grained resolution, fast access times, and support for aperiodic behavior.
Current Timing Hardware
PCs currently use four system timers for different tasks, each with its own distinct set of attributes that make working with all of the timers confusing. The timers currently in use are as follows:
Reasons for a New Timer
Systems today need aperiodic functionality and higher precision. Without these two features, systems will be unable to meet the requirements for future multimedia applications and other time-sensitive applications. The new timer that provides this functionality will replace the 8254 timer, the RTC, the PM clock, and the APIC timer and will enable removal of some of the legacy and redundant hardware in chipsets.
Current Timing Support
When the clock interrupt fires, Windows performs two main actions; it updates the timer tick count if a full tick has elapsed, and checks to see if a scheduled timer object has expired. A timer tick is an abstract notion of elapsed time that Windows uses to track the time of day and thread quantum times consistently. On most systems, a timer tick represents 10 milliseconds, but some systems use 15 milliseconds as the timer tick period. By default, the clock interrupt and timer tick are the same, but the OS or applications can change the clock interrupt period, while the timer tick period never changes. So, a timer tick always represents a constant period, regardless of the period of the clock interrupt underneath.
In addition to maintaining timer ticks, when a clock interrupt is fired the system also checks to see if a timer object has expired, and schedules a timer deferred procedure call (DPC) if one is found. Timer objects are used by the system to track deadlines and to signal applications when a deadline is reached. For example, a multimedia application that is playing synchronized audio and video may request that some code (for example, playing a sound) be executed in 233 milliseconds. Windows keeps track of this request by creating a timer object. It then checks for expired timer objects when a clock interrupt is generated. As Figure 1 illustrates however, with a 10 millisecond clock interrupt period, the operating system will actually play the sound 7 milliseconds late. The operating system checks its timer objects at 230 milliseconds and sees none have expired, and it then checks again at 240 milliseconds and sees the outstanding request. In this case, the granularity of the clock interrupt is too great and end users will perceive audio/video synchronization problems.
Figure 1. Periodic Interrupts Firing Every 10 Milliseconds
The obvious drawback of this implementation is that a large clock interrupt period could result in long delays. For an application to be notified with more precision on todays systems, it must request a smaller clock interrupt period. In the previous example, if the multimedia application wanted its code executed precisely on time, it would request a clock interrupt period of 1 millisecond. Then, the system would check every millisecond to see if there was work to do, as is illustrated in Figure 2.
Figure 2. Periodic Interrupts Firing Every 1 Millisecond
While this allows the multimedia application to execute its code and play a sound on time, it also degrades overall system performance. Microsoft tests have found that, while lowering the timer tick frequency to 2 milliseconds has a negligible effect on system performance, a timer tick frequency of less than 2 milliseconds can significantly degrade overall system performance. On faster systems, the cost of lowering the clock interrupt period below 2 milliseconds may become affordable, but the subtle effect of the increased interrupt frequency on cache consistency and power management may not be desirable.
Future Aperiodic Support
Figure 3. Aperiodic Interrupt Fires at Specific Time Requested
In addition to the performance benefits, aperiodic functionality will also positively contribute to the achievable battery life of mobile platforms. Mobile systems currently enter into a low power state when there is no system activity, but they are regularly pulled back into higher power states when the system clock generates its periodic interrupt. To extend the amount of time mobile systems can remain in low power states, and therefore increase battery life, system designers are currently trying to increase the period of the system clock. This would allow a system to remain in a low powered state for a longer period of time, but it would also cause pre-scheduled events to be started even later. A compromise between the needs of power management and those of applications is for the system to remain totally inactive when no work is needed and to only wake when a scheduled task or alarm is generated. Aperiodic functionality enables this optimal solution.
Because of the high cost of programming existing timers, aperiodic functionality is only realistically possible on a system with an improved timer.
Current timers theoretically have a maximum resolution of 1 millisecond and an achievable resolution of 2 milliseconds because of performance concerns. In addition, existing timers can be up to 1 millisecond late, which means the best resolution an application can depend on is 3 milliseconds. Multimedia applications, however, require an accuracy of at least 1 millisecond; so, while current timers are theoretically adequate for todays multimedia applications, they are unable to meet this minimum requirement in reality.
To get tolerable multimedia performance on a system with current timing hardware, developers have had to develop tricks and techniques, such as large playback buffers and busy waiting, which sacrifice performance and quality to hide the shortcomings of the timing hardware. Because of these tricks and techniques, multimedia applications on a general purpose system with the current timing hardware will never be able to achieve the high quality performance and high level of responsiveness that consumers demand from dedicated units.
High definition video playback and synchronization requires 1 millisecond resolution to decode and perfectly synchronize video frames and audio streams. Sophisticated graphics packages require microsecond granularity so they can correctly animate lip movements to match spoken words. Embedded solutions and high speed soft devices, such as soft DSL, both require microsecond granularity. To satisfy the requirements of multimedia and other time-sensitive applications, a new timer is needed that can generate interrupts at least every millisecond without drifting excessively and generating an interrupt more than a few milliseconds late.
Because time-sensitive applications and solutions are a key component of Microsofts future strategy, the Windows Logo Program for Hardware will eventually require the presence and quality of a High Precision Event Timer.
Although the current timers are still in use and still function properly, they do not meet the needs of time-sensitive applications and depend on legacy technologies such as the Industry Standard Architecture (ISA) bus. To migrate away from these legacy technologies, and to eliminate redundant hardware in the chipset, a new timer is needed that can replace the existing hardware.
The High Precision Event Timer
The High Precision Event Timer (HPET) was developed jointly by Intel and Microsoft to meet the timing requirements of multimedia and other time-sensitive applications. Originally, the HPET was called the Multimedia Timer (MM Timer), but the name was later changed to avoid confusion with a Microsoft DirectX timer, and to better describe the timer.
Benefits of the HPET
In a test that compared the performance of the HPET to that of the PM clock, a function that called the usermode QueryPerformanceCounter() API 1000 times was executed and timed. To ensure the results were comparable, the test was run multiple times on a single system. A similar test was run using the kernel mode KeQueryPerformanceCounter() API on the same hardware to identify the kernel mode benefits of the new timer. Table 1 shows the results of these two experiments.
Table 1 Comparison between HPET and PM Clock Performance
This data shows that reading the timestamp from the HPET is more efficient and faster than with legacy timers. However, because of the fine level of resolution needed for measurement, the actual performance benefits of the HPET and their implications on applications are impossible to quantify.
Migration to the HPET
Windows Support of the HPET
Chipset vendors should implement an HPET to comply with Intels "IA-PC HPET (High Precision Event Timers) Specification". This spec will be available on Intels web site in the second quarter of 2002 with royalty free licensing terms.
Microsoft is in the process of adding the requirements for the HPET to the Windows Logo Program for Hardware to check for the presence and quality of the HPET in chipsets. Although no timeline has been set in regard to when this hardware will be required for a logo, Windows Hardware Quality Lab (WHQL) tests will begin testing the quality of the HPET, if it is implemented, in the timeframe of the release of Windows Vista. Some of the requirements stated in Intels HPET spec are re-articulated below.
Microsecond Granularity and Nanosecond Accuracy
The HPET should have a programmable granularity as is described in Intels HPET spec. Additionally, the timer should have nanosecond accuracy so that interrupts are not generated or delivered late, and minimal drift so that it is consistently reliable.
Main Counter and Comparators
Monotonically Increasing Counter
Periodic and Aperiodic Support
Memory Mapped Set
Call to Action
Following are some of the key acronyms and terms used in this article.
Multimedia Timer (MM Timer)
Real-time clock (RTC)