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

  Introduction
  Current Timing Hardware
  Reasons for a New Timer
  The High Precision Event Timer
  Timer Requirements
  Call to Action
  Glossary

Introduction

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:

8254 PIT
The 8254 Programmable Interval Timer (PIT) was introduced in the IBM PC in 1981. It has a resolution of 1 millisecond and supports both periodic and aperiodic modes. However, because reads from and writes to this hardware require communication through an IO port, programming it takes several cycles, which is prohibitively expensive for the OS. Because of this, the aperiodic functionality is not used in practice. For this reason, this timer is only used in periodic mode to provide the periodic clock interrupt on uni-processor systems.

RTC
In 1984, the IBM-AT shipped with the first real-time clock (RTC) in addition to the 8254. Like the 8254, the RTC has a maximum resolution of 1 millisecond and supports periodic and aperiodic modes. As with the 8254, communication with this hardware occurs through an IO port, and is therefore prohibitively expensive. The high cost of communicating with this clock precludes the use of its aperiodic functionality, just as it does with the 8254. In addition to these limitations, the RTC was designed to generate Advanced Configuration and Power Interface (ACPI) interrupts on ACPI capable systems, which degrades system performance. The RTC is used in periodic mode to provide the system profiling interrupt on uni-processor systems and the clock interrupt on multi-processor systems.

APIC Timer
The Advanced Programmable Interrupt Controller (APIC) timer has many of the capabilities of the real-time clock and was designed to be used to synchronize multiple processors, but it has poor resolution and the clocks silicon is sometimes very buggy. Because many of todays systems still do not have an APIC timer, it is not used by default. More importantly however, this timer is subject to pausing during processor power management in some implementations, making it useless for keeping reliable time on modern systems. For these reasons, this timer is seldom used.

PM Clock
The ACPI timer, also known as the PM clock, was added to the system architecture to provide reliable timestamps independently of the processors speed. Because this was the single goal of this timer, it was designed to provide a time stamp in a single clock cycle, but it does not provide any other functionality.

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.

Aperiodic Functionality

Current Timing Support
Microsoft Windows XP uses a periodic clock interrupt to keep track of time, trigger timer objects, and decrement thread quantum. When Windows XP boots, the typical default clock interrupt period is 10 milliseconds, although a period of 15 milliseconds is used on some systems. That means that every 10 milliseconds, the operating system receives an interrupt from the system timer hardware.

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
In the previous example, the clock interrupt period was lowered to 1 millisecond to play a sound at a precise time. This resulted in 10 interrupts being generated between the times 230 milliseconds and 240 milliseconds while only one interrupt was actually needed. A better approach to this problem is to only schedule an aperiodic timer interrupt when there is work to be done. Then, the timer would only fire once at 233 milliseconds, and the system would never waste time processing unnecessary interrupts. Figure 3 illustrates this behavior.

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.

Improved Resolution

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.

Legacy Reduction

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
Experiments on prototype HPET hardware by Microsoft Test Engineers have shown that, in addition to extending the capabilities and precision of a system, the HPET also improved system performance.

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

Benchmark1000 consecutive [K]QPC calls	PM Clock[calls/ms][µs / call]	HPET[calls/ms][µs / call]	Perf Increase using the HPET
QueryPerformanceCounter()	6301.59	7841.27	24%
KeQueryPerformanceCounter()	11940.84	19200.59	61%

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
The next generation of chipsets will need to support both the HPET and legacy timers. This approach will maintain compatibility with Windows XP and older versions of Windows while enabling the migration to the new timer. Eventually however, chipsets can ship without support for the legacy 8254 timer, PM clock, and APIC timer.

Windows Support of the HPET
Initially, on systems with an HPET, all Windows timer APIs will be ported to the new hardware rather than using the legacy 8254, RTC, APIC, or PM clock. After the HPET is widely available, Windows timer APIs will be extended and the underlying Windows timer code will be enhanced to take advantage of the enhanced capabilities of the HPET.

Timer Requirements

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
The main counter of the High Precision Event Timer should be a monotonically increasing clock with a frequency of at least 10 megahertz (MHz).

Independent Comparators
The timer should have at least three comparator registers that each generates independent interrupts so that each comparator can be used independently.

Exclusive Interrupts
In addition to generating independent interrupts, each comparator must have a unique (non-shared), edge-triggered interrupt in LegacyIRQRouting mode. This is required because timer interrupts are used extensively during regular operations, and processing the interrupt service routine (ISR) of a shared interrupt is more expensive than processing an exclusive interrupt.

Periodic and Aperiodic Support
Each comparator must support aperiodic functionality. At least one comparator must also support periodic functionality.

Register Requirements

Memory Mapped Set
The registers of the timer should be defined as a non-indexed set and mapped to main memory so that each timer can be directly accessed without a lookup.

32-bit Width
The registers of the timer should all be 32 bits wide to provide adequate resolution and functionality, and to minimize roll-over events. HPET implementations that support 64-bit widths will be used in 32-bit mode.

Call to Action

• For system manufacturers: Use new chipset designs that include a High Precision Event Timer in your systems and provide Microsoft with prototype systems to test.

• For chipset vendors: Include a high precision event timer in future chipset designs that meet the guidelines outlined in this article.

Glossary

Following are some of the key acronyms and terms used in this article.

8254 PIT
Programmable Interval Timer, one of the system timers in use today.

Aperiodic timer
A "one-shot" timer that only generates a single interrupt at a specified time. If subsequent interrupts are required after an interrupt is generated, the timer must be reprogrammed.

APIC timer
Advanced Programmable Interrupt Controller timer, one of the system timers in use today.

Clock interrupt
The periodic interrupts, generated by the system timing hardware (typically the 8254 clock), which the OS uses to track time and trigger events. The clock interrupt period can vary over time.

HPET
High Precision Event Timer, the new timer.

Multimedia Timer (MM Timer)
The original name of the HPET. Also a peripheral timer used by graphics packages.

Periodic timer
A timer that generates interrupts at regular, periodic intervals.

Peripheral timer
A proprietary timer that provides some specific, non-essential functionality such as the watchdog timer support used by failover systems.

PM clock
One of the system timers in use today.

Real-time clock (RTC)
One of the system timers in use today.

System timer
A timer that is used by the system to provide fundamental time functionality, such as tracking the time of day and triggering scheduled time-based events.

Timer object
Used by Windows to track requests for a signal at a specific precise time. Timer objects are checked at each clock interrupt to see if the time the object was supposed to expire has passed and schedule a timer DPC to generate a signal or run code for each object that has expired.

Timer tick
An abstract notion used by Windows to consistently track time and thread quantum. The period of a timer tick does not change after boot, while the period of the clock interrupt that physically measures time on the system may change.