Community hub
0 subscribers7 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to High Precision Event Timer.
Nothing was collected or created yet.
High Precision Event Timer
View on Wikipediafrom Wikipedia
 | This article needs additional citations for verification. (February 2014) |
The High Precision Event Timer (HPET) is a hardware timer available in modern x86-compatible personal computers. Compared to older types of timers available in the x86 architecture, HPET allows more efficient processing of highly timing-sensitive applications, such as multimedia playback and OS task switching. It was developed jointly by Intel and Microsoft and has been incorporated in PC chipsets since 2005. Formerly referred to by Intel as a Multimedia Timer,[1] the term HPET was selected to avoid confusion with the software multimedia timers introduced in the MultiMedia Extensions to Windows 3.0.[2]
Older operating systems that do not support a hardware HPET device can only use older timing facilities, such as the programmable interval timer (PIT) or the real-time clock (RTC). Windows XP, when fitted with the latest hardware abstraction layer (HAL), can also use the processor's Time Stamp Counter (TSC), or ACPI Power Management Timer (ACPI PMTIMER), together with the RTC to provide operating system features that would, in later Windows versions, be provided by the HPET hardware. Confusingly, such Windows XP systems quote "HPET" connectivity in the device driver manager even though the Intel HPET device is not being used.
Features
[edit]An HPET chip consists of a 64-bit up-counter (main counter) counting at a frequency of at least 10 MHz, and a set of (at least three, up to 256) comparators. These comparators are 32 or 64 bits wide. The HPET is programmed via a memory mapped I/O window that is discoverable via ACPI. The HPET circuit in modern PCs is integrated into the southbridge chip.[a]
Each comparator is programmed with a value, and can generate an interrupt when the main counter value matches the programmed value, or, in 32-bit mode, every time the low 32-bit half of the main counter value wraps around to zero. The comparators can be put into one-shot mode or periodic mode, with at least one comparator supporting periodic mode and all of them supporting one-shot mode. In one-shot mode the comparator fires an interrupt once when the main counter reaches the value stored in the comparator's register, while in the periodic mode the interrupts are generated at specified intervals.
Comparators can be driven by the operating system, e.g. to provide one timer per CPU for scheduling, or by applications.
Applications
[edit]The HPET can produce periodic interrupts at a much higher resolution than the RTC and is often used to synchronize multimedia streams, providing smooth playback and reducing the need to use other timestamp calculations such as an x86-based CPU's RDTSC instruction. This provides improved efficiency, since the CPU does not need to waste cycles to make up for the low resolution of timers, and enables more aggressive use of sleep states, reducing power consumption. In addition to the application-level demand for high-precision clock, there are OS-level benefits in the scheduler and through the availability of a stable clock base for multi-processor systems.[3]
Comparison to predecessors
[edit]![[icon]](https://en.wikipedia.org/wiki/File:Wiki_letter_w_cropped.svg){kind=small} | This section needs expansion with: compare with LAPIC timer, ACPI PM etc.. You can help by adding to it. (February 2014) |
HPET is meant to supplement and replace the 8254 programmable interval timer and the RTC's periodic interrupt function. Compared to these older timer circuits, the HPET has higher frequency and wider 64-bit counters (although they can be driven in 32-bit mode).[1]
The HPET specification does not define the timer frequency, only requiring a minimum of 10 MHz; the actual frequency is provided to the operating system by a hardware register giving the number of femtoseconds per period (with an upper bound of 100000000 fs). A popular value is 14.318 MHz, 12 times the standard 8254 frequency of 1.19318 MHz.
While 8254 and RTC can be put into an HPET-like one-shot mode, the set-up process is so slow that their one-shot mode is not used in practice for tasks requiring precise scheduling.[4] Instead, 8254 and RTC are typically used in periodic mode with a very small time interval. For example, if an application needs to perform several short (some milliseconds, perhaps) waits, it is better to have a periodic timer running constantly with a 1 ms period because of the high setup cost of an 8254 or RTC one-shot timer. This causes an interrupt at every millisecond even if the application needs to do actual work less frequently. With HPET, the extra interrupts can be avoided, because the set-up cost of a HPET one-shot timer is considerably smaller.
Use and compatibility
[edit]
Operating systems designed before HPET existed cannot use HPET, so they use other timer facilities. Newer operating systems tend to be able to use either. Some hardware has both. Indeed, most current southbridge chips have legacy-supporting instances of PIT, PIC, Advanced Programmable Interrupt Controller (APIC) and RTC devices incorporated into their silicon whether or not they are used by the operating system, which helps very modern PCs run older operating systems.
The following operating systems are known not to be able to use HPET: Windows XP SP1,[b] and earlier Windows versions, Linux kernels prior to 2.6.[c]
The following operating systems are known to be able to use HPET: Windows XP SP3,[d] Windows Server 2003 SP2, Windows Server 2008, Windows Server 2008 R2, Windows Vista, Windows 7, x86 based versions of OS X, Linux operating systems using the 2.6 kernel (or later), FreeBSD[5] and OpenSolaris.[citation needed]
The Linux kernel can also use HPET as its clock source. The documentation of Red Hat MRG version 2 states that TSC is the preferred clock source due to its much lower overhead, but it uses HPET as a fallback. A benchmark in that environment for 10 million event counts found that TSC took about 0.6 seconds, HPET took slightly over 12 seconds, and ACPI Power Management Timer took around 24 seconds.[6]
In 2019 it was decided to blacklist HPET in newer Linux kernels when running on some Intel CPUs (Coffee Lake) because of its instability.[7]
Problems
[edit]HPET is a continuously running timer that counts upward, not a one-shot device that counts down to zero, causes one interrupt and then stops. Since HPET compares the actual timer value and the programmed target value on equality rather than "greater or equal", interrupts can be missed if the target time has already passed when the comparator value is written into the chip's register.[8] In such a case, not only is the intended interrupt missed, but actually set far into the future (about 232 or 264 counts).[9] In the presence of non-maskable interrupts (such as a System Management Interrupt (SMI)) that do not have a hard upper bound on their execution time, this race condition requires time-consuming re-checks of the timer after setup and is hard to avoid completely. The difficulties are exacerbated if the comparator value is not synchronized with the timer immediately, but delayed by one or two ticks, as some chipsets do.[8]
Besides mentioning the race condition discussed above, a VMware document also lists some other drawbacks: "The specification does not require the timer to be particularly fine grained, to have low drift, or to be fast to read. Some typical implementations run the counter at about 18 MHz and require about the same amount of time (1–2 μs) to read the HPET as with the ACPI timer. Implementations have been observed in which the period register is off by 800 parts per million or more."[9]
Notes
[edit]- ^ On these highly integrated dies the BIOS often sets up the HPET incorrectly in the ACPI, initializing it correctly only in Intel 8253 mode. If the ACPI is not set up correctly the OS cannot list the HPET. And the BIOS and OS developers don't see the need to get Real Time support. So the HPET is only there to satisfy the system's high speed needs. If the HPET is set up correctly in the ACPI from BIOS then the ACPI MMIO page of the first HPET chip should be at 0xFED00000 and the second HPET at page 0xFED80000 (see the discussion for further information).
- ^ Windows XP, SP2 knows the HPET timer (as a device with ACPI\PNP0103 identifier). When detected (for example, on Intel DQ45CB motherboard), Device Manager (Start / Settings / Control Panel / System / Device Manager) shows "High Precision Event Timer" device in "System devices" branch. But this device is not used at all.
- ^ With a Linux kernel, you need the newer RTC-CMOS hardware clock device driver rather than the original RTC driver.
- ^ XP SP3 "emulates" most of the HPET specification as drafted in 2002 in anticipation of a device that made its eventual appearance in PCs designed for Windows Vista by 2005. The term "High Precision Event Timer" is then used within the driver manager to describe TSC (Time-Stamp-Counter) or ACPI Power Management Timer (PMTimer) timing subsystems even when the 15 MHz Intel HPET device is not being used. While it is true to say that only Windows Vista and later Windows use the physical Intel 15 MHz HPET, the operating system features intended to be fulfilled by the HPET already largely existed in Windows XP, albeit to a different specification (that of 2002 rather than 2005) and hence with a reduced capability. In terms of physical embodiment in Windows XP SP3, the IRQ0 and IRQ8 are typically mapped to a "High Precision Event Timer" when using the ACPI HAL (version 5.1.2600.5512), albeit that the QueryPerformanceFrequency API call returns a value related to the rated processor clock speed (for example, 2.6 GHz) or PMTIMER (3.579545 MHz) rather than the Intel HPET spec'd value of 15 MHz that you would get using Windows Vista. This anomaly muddies the water about what is meant by "HPET" on such systems, but it is clearly not the 15 MHz Intel device in those cases. Note that this "HPET"-quoting IRQ mapping and non-HPET clock relationship can be found both on Intel systems and AMD systems whether or not they are using the /USEPMTIMER boot override. Since the original specification for HPET (in 2002) calls for a high resolution counter, which is then exposed by the QueryPerformanceFrequency and QueryPerformanceCounter API calls (already available since Windows 2000), it is the QueryPerformanceFrequency that can shed light on how this "high precision" counter is actually being provided. A high value (in the 1 GHz to 4 GHz range) implicates the Time Stamp Counter (TSC) of the CPU as being the source. The early multi-core CPUs from AMD exposed a problem with TSC-derived QueryPerformanceCounter readings, as they would be affected by spread-spectrum and power management speed variations. While this was eventually solved in later processor designs by making the TSC clock independent of the CPU clock, the PM Timer on ACPI systems became the counter source of choice, requiring a /USEPMTIMER override in the Windows BOOT.INI file to enforce its use. On both Intel and AMD machines using the ACPI HAL together with the /USEPMTIMER boot switch, the IRQs 0 & 8 will still report a HPET, but now the QueryPerformanceFrequency will report 3.579545 MHz, which is the frequency of the PMTIMER. This has the express advantage of being independent of the CPU frequency and still provides a very reasonable sub-microsecond resolution and accuracy. Ironically the very high count rates obtained in TSC mechanisms (as compared with PMTIMER or the Intel HPET device) can cause a problem that the measurable time intervals are too short: there is an upper limit to the usefulness of a counter that overflows early. It can also be a nuisance that the ever-increasing processor speeds of newer processor designs make this usable time span shorter still. It is thus not surprising that PMTIMER and Intel HPET systems use a clearly specified fixed rate that is deliberately targeted at producing resolutions in the sub-microsecond range, allowing them to measure for longer periods than is possible with TSC. With or without the /PMTIMER switch, the "event" part of the HPET specification can only be emulated by using yet another timing source, since neither an underlying TSC nor PMTIMER solution includes implicit hardware for aperiodic event triggering as described by the specification, and yet this is available via the timer API in Windows XP (to a best possible resolution of 0.9766 ms when the timeBeginPeriod - timeEndPeriod API calls are used). This part of the specification is still fulfilled by the RTC device with the help of software, despite the fact that the device manager is quoting HPET in the IRQ0 and IRQ8 positions.
References
[edit]- ^ a b Intel Corporation (October 2004), IA-PC HPET (High Precision Event Timers) Specification (revision 1.0a) (PDF), retrieved 2012-06-15
- ^ "Multimedia Timers". Microsoft. 10 December 2007. Retrieved 2010-10-20.
- ^ "IA-PC HPET (High Precision Event Timers) Specification" (PDF). Intel. October 2004. Retrieved 30 August 2022.
- ^ Guidelines For Providing Multimedia Timer Support, 2002-09-20, retrieved 2009-11-10
- ^ "FreeBSD Man Pages: hpet(4)". www.freebsd.org.
- ^ "Chapter 15. Timestamping". Access.redhat.com. Archived from the original on 2016-05-07. Retrieved 2014-02-14.
- ^ "The Linux Kernel Disabling HPET For Intel Coffee Lake". Phoronix.
- ^ a b Thomas Gleixner, x86: hpet: Work around hardware stupidity Archived 2012-07-09 at archive.today, commit merged for Linux kernel 2.6.36-rc5
- ^ a b Timekeeping in VMware Virtual Machines (for VMware vSphere 5.0, Workstation 8.0, Fusion 4.0), page 9
High Precision Event Timer
View on Grokipediafrom Grokipedia
The High Precision Event Timer (HPET) is a hardware timer architecture for Intel Architecture-based personal computers, developed jointly by Intel and Microsoft to deliver high-resolution timing capabilities that surpass those of legacy timers like the 8254 Programmable Interval Timer (PIT) and Real-Time Clock (RTC).[1][2] Defined in the IA-PC HPET Specification version 1.0a released in October 2004, it features a 64-bit main counter operating at a minimum frequency of 10 MHz with a drift tolerance of ±0.05% (500 ppm) over intervals of 1 millisecond or longer, enabling precise event scheduling and synchronization.[1]
HPET's primary purpose is to support time-sensitive applications, including real-time audio and video stream synchronization, thread and task scheduling, system heartbeat monitoring, and high-accuracy time-stamping on multiprocessor systems, by providing a platform-wide shared timer resource that avoids the inconsistencies of per-processor Time Stamp Counters (TSC) in certain scenarios.[1][2] The architecture supports up to 256 independent timers organized in blocks of 32, with each block containing a minimum of three 32-bit comparators (optionally 64-bit with 32-bit mode fallback), allowing for both one-shot (non-periodic) and periodic interrupt modes.[1] Timers are memory-mapped in a 1024-byte register space per block and can route interrupts via legacy replacement, standard I/O APIC, or Front Side Bus (FSB) mechanisms, with operating systems able to assign specific timers to applications for optimized performance.[1]
In Microsoft Windows, HPET was introduced as a platform timer option starting with Windows Vista and became a requirement for Windows 7 and 8 hardware certification, serving as the basis for the QueryPerformanceCounter (QPC) API when TSC proves unreliable due to factors like processor frequency scaling or lack of invariance.[2] Although it offers superior accuracy for cross-processor synchronization compared to earlier timers, HPET incurs higher access latency—typically 0.8 to 1.0 microseconds—than TSC, making it a shared resource best suited for scenarios prioritizing precision over raw speed.[2] Modern implementations in Intel chipsets, such as those in Core Ultra processors, continue to include HPET with at least eight timers per Platform Controller Hub (PCH), ensuring compatibility for legacy and specialized timing needs.[3]
Definition and Purpose
Overview
The High Precision Event Timer (HPET) is a hardware timer architecture designed for x86-compatible personal computers, consisting of a 64-bit monotonically increasing main counter clocked at a frequency of at least 10 MHz.[1] This counter serves as the foundation for generating high-resolution timestamps and periodic interrupts with low jitter, enabling precise timing operations in modern computing environments.[1] HPET's primary purpose is to deliver accurate, stable timing events for operating system kernels, device drivers, and applications, particularly those requiring sub-microsecond precision, such as multimedia synchronization, thread scheduling, and real-time task management.[2] It was developed to supplement and eventually replace legacy timers like the 8254 Programmable Interval Timer and Real-Time Clock, which suffer from higher jitter and lower resolution due to their slower clock rates and interrupt overhead.[1] By providing consistent performance across system states, including power management modes, HPET addresses the growing demands for reliable timing in multitasking and time-sensitive workloads.[2] At its core, the HPET features a single shared main counter accessible by multiple configurable timer channels, allowing independent event programming without contention.[1] Systems can implement up to 32 channels per timer block (with a maximum of 256 across eight blocks), though most hardware provides 3 to 8 channels to balance functionality and resource use.[1] The architecture was jointly developed by Intel and Microsoft, with the initial specification released by Intel in October 2004 and subsequent integration into PC chipsets beginning in 2005.[1][2]Design Goals
The High Precision Event Timer (HPET) was developed to address limitations in legacy timing mechanisms for IA-PC systems, with primary goals centered on delivering microsecond-level precision for time-sensitive operations, minimizing timer access overhead, enabling multiple independent timers for parallel workloads, and maintaining full compatibility with Advanced Configuration and Power Interface (ACPI) power management standards. These objectives aimed to support applications such as real-time audio/video synchronization, precise thread scheduling, system heartbeat monitoring, and event time stamping in multiprocessor environments. By providing a 64-bit free-running main counter, HPET ensures a stable, high-resolution time base that outperforms earlier timers in accuracy and flexibility.[1] To achieve the required precision, the HPET specification targets a clock frequency range of at least 10 MHz to enable a resolution of 100 nanoseconds or better per counter tick, with implementations often extending up to 25 MHz for even finer granularity in demanding scenarios. The design mandates low drift characteristics, including accuracy within 0.05% (500 parts per million) over intervals of 1 millisecond or longer, and a maximum error of two ticks (no more than 200 nanoseconds) over 100 microseconds, which collectively reduce timing jitter and variations in interrupt delivery far below levels typical of predecessors like the 8254 Programmable Interval Timer (PIT) or Real-Time Clock (RTC). This jitter reduction enhances reliability for periodic and one-shot timing events without excessive system load.[1][4] Integration goals emphasize efficient hardware-software interfacing through memory-mapped I/O, which allows direct CPU access to timer registers without the indexing overhead of legacy ports, thereby lowering latency for frequent reads and configurations. The architecture supports level-triggered or edge-triggered interrupts, routable via standard mechanisms like the I/O APIC or Front Side Bus, to facilitate precise event notification. For scalability in multi-core systems, HPET provisions up to eight timer blocks—each with as many as 32 independent comparators—enabling concurrent timer operations across processors while adhering to ACPI 2.0 via a dedicated HPET Description Table for discovery and power-state handling.Technical Details
Architecture
The High Precision Event Timer (HPET) is implemented as a memory-mapped I/O device with a 1024-byte register block, aligned on a 64-bit boundary and consuming 1 KB of address space. The base address of this block is assigned by the BIOS and reported through ACPI tables, specifically the HPET Description Table, which provides details on the timer's presence, capabilities, and location in physical memory. The register block includes the General Capabilities and ID Register (GCAP_ID) at offset 00h, which identifies the number of timers (up to 32), revision, and counter size (32-bit or 64-bit); the General Configuration Register at offset 010h for enabling the timer and configuring legacy modes; the main counter register (MC) at offset 0F0h; and per-timer registers starting at offset 100h, with each of the up to 32 timer channels occupying 32 bytes (20h).[1] At the core of the HPET is a single 64-bit (or optionally 32-bit) main counter that operates as a monotonic up-counter, incrementing at a fixed rate of 10 MHz with an accuracy of ±500 ppm over 1 ms intervals. This counter is fully read- and write-accessible when enabled but pauses when the HPET is disabled via the General Configuration Register, ensuring no partial increments during reconfiguration. It wraps around after approximately 264 ticks, equivalent to roughly 58,497 years at 10 MHz, providing a virtually non-overflowing timescale for high-precision timing. The counter's value serves as the reference for all timer channels, enabling synchronized event generation across the system. Each of the up to 32 timer channels functions as a comparator against the main counter, featuring a 64-bit Configuration and Capabilities Register (T_n_CONFIG) and a 64-bit Comparator Value Register (T_n_CMP). The T_n_CONFIG register controls timer-specific settings, including enable/disable (bit 2), interrupt routing including IOAPIC vector selection via Tn_INT_ROUTE_CNF (bits 9–13) and capabilities in bits 32–63 or to legacy PICs, periodicity for periodic mode (bit 3), and edge- or level-triggered interrupts (bit 1). In one-shot mode, the comparator triggers an interrupt once when the main counter matches the value in T_n_CMP; in periodic mode, the comparator value auto-increments by the programmed period after each match, allowing recurring events without software intervention. Interrupts from these channels can be routed via traditional 8259 PICs, IOAPIC for local APIC delivery, or front-side bus (FSB) interrupts, supporting up to 256 total timers across multiple blocks if implemented.[1] Regarding power management, the HPET main counter continues to run during processor C-states (C1 through C3) and system sleep states S1 and S2, maintaining timing continuity except when the system is fully powered off or in deeper sleep states (S3, S4, S5), where register contents are not preserved and must be reinitialized. An optional legacy replacement mode, enabled via bit 1 in the General Configuration Register, allows the HPET to emulate older timer behaviors for compatibility, such as routing to the 8259 PIC instead of modern interrupt mechanisms. This design ensures the HPET remains operational in low-power scenarios without requiring full system resets for timing recovery.[1]Key Features
The High Precision Event Timer (HPET) provides support for multiple logical timers, with up to 32 timers per timer block sharing a single main 64-bit counter. Each timer operates via a dedicated comparator register and can be configured independently for one-shot or periodic events through settings in the T_n_CONFIG register, including bits for timer enable, interrupt route selection, and mode (one-shot or periodic). This multi-timer architecture enables concurrent high-precision timing for diverse system events, such as scheduling and synchronization, without the limitations of single-timer legacy hardware.[1] HPET delivers interrupts with flexible capabilities, supporting fixed-rate periodic interrupts configurable from rates like 1 kHz to 100 kHz, and allowing level- or edge-triggered modes. Interrupts can be routed via legacy replacement (e.g., to IRQ0 or IRQ8), standard I/O APIC messaging, or Front Side Bus (FSB) delivery for direct CPU access in multi-processor systems, with Message Signaled Interrupts (MSI) as an optional enhancement for scalability. These features ensure reliable, low-latency interrupt handling suitable for real-time applications.[1][5] A core strength of HPET is its high temporal resolution, derived from the main counter's minimum 10 MHz frequency, yielding an effective 100 ns tick interval and femtosecond-level precision in period measurements. Unlike legacy timers reliant on crystal oscillators, HPET's counter—often sourced from the system bus clock—exhibits no inherent drift, providing stable timing over extended periods with accuracy better than ±0.05% for intervals of 1 ms or more.[1] Vendor-specific extensions enhance HPET implementations, with the Vendor ID field in the General Capabilities and ID Register (offset 0x000) identifying the manufacturer and enabling optional capabilities such as additional timer blocks beyond the standard single block or up to 256 total timers across multiple blocks. For instance, Intel and AMD implementations may include reserved bits in configuration registers (e.g., bits 15:8 in the General Configuration Register) for proprietary features like extended interrupt capabilities, though these remain optional and non-standardized.[1]Programming Model
The programming model for the High Precision Event Timer (HPET) enables software, including operating system kernels, to discover, initialize, and configure the timer hardware through memory-mapped I/O registers. The primary mechanism for locating the HPET involves parsing the ACPI HPET Description Table, which provides the base address of the HPET register block in a 12-byte Generic Address Structure (GAS) format at offset 40h within the table.[1] This table is part of the ACPI namespace and reports the hardware's presence, event timer block ID, and address space details, ensuring portability across compatible systems.[1] Initialization begins with reading the General Capabilities and ID Register (GCAP_ID) at offset 00h, a read-only 64-bit register that reveals key hardware attributes such as the number of timers (bits 12:8), counter size (bit 13 indicating 32-bit or 64-bit), vendor ID (bits 31:16), and the clock period in femtoseconds (bits 63:32).[1] Based on these capabilities, software then writes to the General Configuration Register at offset 010h to enable the main counter by setting the ENABLE_CNF bit (bit 0) and optionally configures legacy replacement modes via the LEG_RT_CNF bit (bit 1) for compatibility with older timer routing to IRQ0 or IRQ2.[1] The BIOS typically assigns the memory space for the HPET block (minimum 1 KB aligned) prior to OS handoff, and software must ensure atomic 64-bit reads/writes if operating on a 32-bit system to avoid inconsistencies.[1] To program an individual timer, software configures the Timer N Configuration and Capabilities Register (TNCAP) at offset 100h + (20h * N), where N is the timer index from 0 to the maximum supported by GCAP_ID.[1] This includes setting the timer type via TN_TYPE_CNF (bit 3) for one-shot (non-periodic) or periodic modes, enabling interrupts with TN_INT_ENB_CNF (bit 2), and specifying the interrupt routing through Tn_INT_ROUTE_CNF (bits 13:9) for I/O APIC delivery or Tn_FSB_EN_CNF (bit 14) for Front Side Bus interrupts on older platforms.[1] The actual event is triggered by writing a comparator value to the Timer N Comparator Value Register at offset 108h + (20h * N), typically set to the current main counter value (read from offset 0F0h) plus a desired offset for future events in non-periodic mode; in periodic mode, the hardware automatically increments the comparator by the period value after each match.[1] For 32-bit systems accessing 64-bit timers, the Tn_32MODE_CNF bit (bit 8) forces 32-bit operation to simplify programming. Error handling in the programming model relies on status registers to detect and clear interrupt conditions. The General Interrupt Status Register at offset 020h provides bits indicating which timers have pending interrupts, which are cleared by writing 1 to the corresponding bit (write-1-to-clear semantics for level-triggered).[1] To prevent missed events due to counter wrap-around, software must ensure the comparator value exceeds the current counter value before enabling the timer, particularly in non-periodic mode where the 32-bit counter rolls over after approximately 2^32 ticks (429 seconds or 7.15 minutes at 10 MHz).[1] During system sleep states (S-states), the main counter may continue running in S1/S2 but is typically paused in deeper states like S3/S4/S5, requiring software to save and restore comparator values and configuration upon resume, as register contents are not preserved.[1]History and Development
Origins and Specification
The High Precision Event Timer (HPET) was initiated by Intel Corporation to address the limitations of legacy timers such as the 8254 Programmable Interval Timer (PIT) and [Real-Time Clock](/page/Real-Time Clock) (RTC) periodic interrupts in IA-PC systems, particularly for applications requiring sub-microsecond accuracy.[1] Development began in early 2000 under the provisional name Multimedia Timer, reflecting its initial focus on supporting precise synchronization for multimedia workloads, and evolved through multiple revisions amid the transition to multi-core processors and operating systems like Windows Vista.[6] Intel collaborated closely with Microsoft and the ACPI Special Interest Group (SIG)—comprising Hewlett-Packard, Intel, Microsoft, Phoenix Technologies, and Toshiba—to standardize the hardware.[1] Microsoft assigned the Plug and Play identifier PNP0103 for HPET devices in the ACPI namespace, ensuring seamless integration with operating systems. The formal specification, IA-PC HPET Specification version 1.0a, was released by Intel in October 2004, defining a memory-mapped timer architecture with up to 256 independent timers.[1] HPET was incorporated into the Advanced Configuration and Power Interface (ACPI) Specification 3.0, released in September 2004 and revised in subsequent errata, via the new HPET Description Table that enumerates timer capabilities and base addresses.[7] This specification responded to increasing demands for low-jitter timing in real-time applications, such as audio/video processing and thread scheduling on multi-core systems.[1] Early hardware prototypes appeared in Intel's 945-series chipsets, launched in early 2005, marking the first widespread implementation in consumer platforms. AMD followed with support in later chipset revisions, extending HPET compatibility across x86 architectures.Adoption Timeline
The High Precision Event Timer (HPET) began seeing initial hardware adoption in 2005 with the release of Intel's 945 Express chipset family, which included support for the timer in its platform controller hub.[8] AMD platforms based on the K8 architecture (Athlon 64 and Opteron) also integrated HPET support around this period to align with emerging multimedia and real-time requirements.[9] HPET support was introduced with Windows Vista in 2007. Starting with Windows 7, it became a requirement for the operating system's hardware logo certification program, mandating BIOS-level support for the timer to ensure high-resolution timing capabilities.[10][2] From 2008 to 2012, HPET integration expanded significantly into server and desktop environments, including Intel's Nehalem-based chipsets like the X58 series, which incorporated the timer for enhanced synchronization in multi-core systems.[11] Linux kernel support solidified with the hpet driver introduced in version 2.6.13 (released in 2005) and matured through subsequent updates, enabling reliable detection and utilization across distributions.[12] UEFI firmware specifications, building on ACPI 2.0 tables for HPET detection, began mandating proper enumeration of the timer in system descriptions to facilitate OS handoff.[13] By 2013 to 2020, HPET had become a standard feature in all x86-64 compatible systems, driven by ongoing Windows Hardware Certification requirements and broad chipset inclusion from Intel and AMD.[2] Discussions around deprecation emerged in operating systems favoring the Time Stamp Counter (TSC) for its lower overhead, with Linux kernel developers disabling HPET by default on newer Intel platforms like Coffee Lake and Ice Lake to prioritize TSC stability.[14] From 2021 to 2025, HPET continued to find use in embedded and IoT devices, particularly those relying on x86 architectures for real-time operations, as evidenced by its presence in Intel's 600 Series chipsets targeted at edge computing platforms.[15] The ACPI Specification Release 6.5 (2022) maintained HPET's role in platform timer tables without introducing major changes, focusing instead on general power management enhancements, and no widespread discontinuations have occurred as of 2025.[16]Comparisons
With Predecessor Timers
The High Precision Event Timer (HPET) represents a significant advancement over the legacy Programmable Interval Timer (PIT), such as the Intel 8254, by providing a minimum clock frequency of 10 MHz, resulting in a resolution of 100 ns or better.[1] In contrast, the PIT operates at approximately 1.193 MHz, yielding a coarser tick resolution of about 838 ns.[17] Additionally, HPET employs memory-mapped I/O for access, which incurs lower CPU overhead compared to the PIT's I/O port-based interface, and avoids the delays associated with mode-switching operations required by the PIT's programmable counters.[1][18] Compared to the Real-Time Clock (RTC), typically implemented as the MC146818-compatible chip in x86 systems, HPET delivers a 64-bit main counter that operates independently of battery power, ensuring consistent high-resolution timing without reliance on external backup.[1] The RTC's periodic interrupt function, while useful for coarse timekeeping, supports rates from 1 Hz up to a theoretical 32 kHz (approximately 30 μs granularity), but in practice is limited to lower frequencies like 8 kHz (125 μs) due to hardware constraints, and exhibits higher jitter from its IRQ 8 routing and update cycles.[19][20] HPET also improves upon predecessor concepts like the ACPI Power Management Timer (PMT), a single-channel, free-running 32-bit counter clocked at 3.579545 MHz (about 279 ns resolution) used for power state transitions.[21] Unlike the PMT's limited single-timer design, HPET supports up to 32 independent comparator channels for multi-timer operations and is fully integrated into ACPI tables for enhanced system event handling.[1][22] In multi-tasking environments, these enhancements enable HPET to achieve lower interrupt latencies than the PIT; for instance, HPET configurations can reduce the frequency of interrupts during idle periods, minimizing overhead and improving responsiveness over the PIT's fixed periodic mode.[23]With Modern Alternatives
The High Precision Event Timer (HPET) offers greater reliability in multi-core environments and during system sleep states compared to the Time Stamp Counter (TSC), as HPET operates independently of CPU frequency scaling and core-specific variations, ensuring consistent timing across the system.[24] However, HPET incurs higher latency due to its memory-mapped access mechanism, whereas TSC leverages the low-overhead rdtsc instruction for sub-nanosecond reads, making TSC approximately 20 times faster for frequent timestamping operations.[24] In modern Linux kernels from version 5.x onward, the invariant TSC—available on processors supporting constant rate and non-stop features—is preferred for user-space applications, as it maintains synchronization across cores and power states without HPET's overhead.[25] Compared to the Local APIC Timer, HPET provides superior support for system-wide events through its shared, memory-mapped architecture with up to 32 comparators, enabling efficient interrupt routing for global synchronization tasks without per-core limitations.[26] The Local APIC Timer, being integrated per CPU core, excels in speed for short-duration intervals under 1 μs, achieving precision down to 1 ns in TSC-deadline mode via direct CPU access, which avoids the bus contention inherent in HPET's shared design.[26] In virtualized environments such as those using KVM, HPET emulation introduces significant overhead due to its complexity and the need for hypervisor intervention on memory accesses and interrupts compared to native execution. Paravirtualized clocks like KVM's pvclock mitigate this by providing guest-host time synchronization through lightweight multipliers and offsets applied to the TSC, reducing emulation costs and ensuring accurate timekeeping during VM migrations or scheduling delays.[25] As of 2025, HPET remains the default for certain ACPI-related events requiring system-wide precision, but it is increasingly phased out in favor of TSC-based mechanisms or hybrids in Windows 11 and Linux 6.x kernels, prioritizing power efficiency by disabling HPET on platforms where reliable TSC is available, such as Intel Coffee Lake and later.[14][27]Usage and Compatibility
Hardware Requirements
The High Precision Event Timer (HPET) requires integration into the system's southbridge or platform controller hub, as specified in the IA-PC HPET standard for x86-compatible personal computers. Support begins with chipsets such as Intel's I/O Controller Hub 7 (ICH7) family and later models, where the HPET is embedded within the LPC interface bridge (PCI device 31, function 0), and AMD's SB600 southbridge and subsequent generations.[28][29] Detection of the HPET hardware typically occurs through the ACPI namespace under the _SB_.HPET object.[1] HPET operates exclusively on x86 and x86-64 CPU architectures, leveraging the Advanced Programmable Interrupt Controller (APIC) for efficient interrupt routing to support multi-timer event delivery. It lacks native hardware implementation on non-x86 platforms such as ARM or RISC-V, necessitating software emulation or alternative timers for compatibility in those environments.[1] Firmware support is mandatory via ACPI version 2.0 or higher, which includes the HPET description table to specify the timer's base address—commonly 0xFED00000—and capabilities like timer count and clock period. The system's BIOS or UEFI must explicitly enable the HPET during initialization, as it is often disabled by default in mobile configurations (e.g., certain laptops) to reduce power consumption by favoring lower-resolution timers.[1][29] Additionally, the HPET occupies a dedicated, 1 KB memory-mapped I/O region that must be aligned on 1 KB boundaries (typically 4 KB in practice for system compatibility), ensuring no overlap with legacy timer address spaces like those used by the 8254 PIT or RTC to prevent access conflicts.[28] The BIOS programs this region during early POST, reporting it via ACPI for OS discovery and use.[29]Operating System Support
Windows provides native support for the High Precision Event Timer (HPET) starting with Windows Vista through the hpet.sys driver, which enables the operating system to utilize HPET hardware for high-resolution timing.[30] In Windows 10 and 11, HPET serves as the default clock source for certain timing functions, such as QueryPerformanceCounter, particularly when high precision is required for multimedia applications like video synchronization.[2] Users can configure HPET usage via the Boot Configuration Data (BCD) editor with the commandbcdedit /set useplatformclock true, which forces the system to prioritize platform timers like HPET over alternatives such as the Time Stamp Counter (TSC).
Linux kernels have supported HPET as a clocksource since version 2.6.18, integrating it into the high-resolution timer framework introduced in that release to provide monotonic timestamps for scheduling and timekeeping.[31] The kernel can select HPET automatically if available via ACPI enumeration, or force its use through the boot parameter hpet=force, which is particularly useful on hardware with incomplete documentation, such as certain NVIDIA chipsets.[32] In modern kernels like those in the 6.x series (as of 2025), HPET is preferred over the ACPI power management timer (acpi_pm) for high-resolution operations when TSC is unavailable or unstable, due to its higher resolution and better interrupt handling for real-time tasks, though both incur higher overhead than TSC. As of Linux kernel 5.10 and later, HPET is disabled by default on many Intel platforms (e.g., Ice Lake and newer) to reduce overhead, favoring invariant TSC where available.[24][14]
macOS offers limited direct support for HPET and primarily favors the TSC for timing on Apple hardware.[33]
FreeBSD provides HPET support via the hpet(4) driver, which leverages ACPI to access the hardware's main counter and comparators for kernel timekeeping and event timers, with fallback to TSC if HPET is unavailable.[34] This driver exposes a user-space interface through /dev/hpetN devices, allowing applications to configure timers and read high-precision timestamps directly.[34]
In virtualized environments, VMware ESXi and related products support HPET in virtual machines (configurable in hardware version 8 and above) to maintain timing precision for guest operating systems, providing virtualized access to the timer with resolutions down to 100 ns, though performance may vary based on host hardware and VM configuration.[35] Hyper-V provides synthetic timers for guest compatibility, with fallback to emulated HPET when needed; for full precision in demanding scenarios, device passthrough of the physical HPET hardware to the VM can bypass emulation overhead.[36]
Applications
Real-Time Systems
In real-time operating systems (RTOS), the High Precision Event Timer (HPET) provides schedulable interrupts that enable precise task switching and scheduling, supporting deterministic timing essential for embedded environments. For instance, QNX incorporates HPET support through virtual device emulation, allowing real-time guests to access its high-resolution timers for interrupt-driven operations in virtualized setups. Similarly, VxWorks supports high-performance real-time computing on Intel platforms, where interrupt response times remain independent of CPU load to ensure reliable task management; HPET can be configured as a timer source on such platforms.[37][38] HPET's role extends to industrial applications, such as timing in programmable logic controllers (PLCs) and automotive electronic control units (ECUs), for accurate event stamping. These systems require precise synchronization, contributing to safety-critical operations in automotive environments. HPET supports flexible configuration to meet real-time demands, with periodic mode used for generating consistent heartbeat signals that monitor system health and trigger periodic tasks, and one-shot mode employed for targeted, event-driven responses without ongoing repetition. These modes, combined with HPET's interrupt features, allow RTOS to achieve low-jitter timing suitable for applications requiring sub-millisecond precision.[1]Multimedia and Synchronization
The High Precision Event Timer (HPET) plays a key role in multimedia applications by providing hardware-based, high-resolution timestamps essential for synchronizing audio and video streams with minimal jitter. Developed jointly by Intel and Microsoft, HPET addresses the timing needs of multimedia processing, offering a fixed-rate counter operating at over 10 MHz to support low-latency operations and reduce drift in time-sensitive tasks.[2] In audio timing, HPET enables low-latency buffering and sample synchronization in systems like the JACK Audio Connection Kit on Linux, where it serves as an optional wall clock source for precise event handling at rates such as 44.1 kHz. On Windows, multimedia APIs use high-resolution system timers derived from HPET for accurate playback timing.[39] HPET facilitates synchronization in multimedia software by providing precise timestamps for coordinated audio-video rendering. In Windows Media Foundation, the framework uses high-resolution system counters for timeline accuracy, maintaining lip-sync in media playback through sub-millisecond timestamp precision. Similarly, Linux's PulseAudio employs system clock sources for drift correction in networked audio streams, adjusting sample rates dynamically to prevent cumulative offsets in multi-device setups.[40]Limitations and Issues
Known Problems
The High Precision Event Timer's main counter operates continuously unless explicitly halted by software, contributing to elevated idle power consumption in systems where it is enabled, particularly on laptops where this has prompted BIOS-level options to disable the feature for better battery life.[1] HPET interrupt delivery via Message Signaled Interrupts (MSI) to the Advanced Programmable Interrupt Controller (APIC) introduces overhead from arbitration and routing, resulting in latencies of approximately 5 μs.[41] The 64-bit main counter overflows after roughly 58,000 years at a typical 10 MHz frequency (or less at higher rates up to 100 MHz, around 5,800 years), but short-term reads on 32-bit systems require careful handling to maintain atomicity, as the counter value may wrap during the multi-instruction read process.[1] HPET generally exhibits higher access latency than the Time Stamp Counter (TSC) in modern systems. In modern processors with invariant TSC support, HPET is often not used as the primary timer source due to its higher overhead, serving mainly as a fallback for compatibility.Workarounds and Mitigations
One common mitigation for HPET-related performance degradation in Linux systems, such as intermittent slowness or freezes observed in Red Hat Enterprise Linux 6 on x86_64 architectures with Intel Xeon processors, involves disabling the HPET device entirely. This can be achieved by appending the kernel parameterhpet=disable to the bootloader configuration, which forces the system to fall back to alternative timers like the Time Stamp Counter (TSC) or ACPI Power Management Timer (PMT).[42][43]
In environments requiring low-latency operation, such as real-time applications, HPET's slower read performance compared to TSC—due to accessing a memory-mapped area rather than a CPU register—can be addressed by dynamically selecting a faster clock source. Administrators can verify available sources via /sys/devices/system/clocksource/clocksource0/available_clocksource and switch temporarily with echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource as root, or make changes persistent through kernel tuning files. However, HPET remains a viable fallback on systems lacking reliable TSC, provided its availability is confirmed, as not all hardware supports it reliably.[44][45]
At the hardware level, issues with 64-bit timer programming on 32-bit processors primarily affect reads due to potential race conditions during multi-dword access; writes to 64-bit comparator registers should use sequential 32-bit accesses to the low and high dwords. To prevent missed interrupts from counter rollover, comparators must be programmed with values sufficiently ahead of the current main counter value, ideally by at least the maximum interrupt latency.[1]
Interrupt routing limitations, where many x86 BIOSes fail to enable HPET interrupts in non-legacy mode, can be circumvented by operating in legacy replacement mode. This uses the first two comparators to emulate the 8254 Programmable Interval Timer (PIT) and Real-Time Clock (RTC) interrupts, allowing HPET to serve as a drop-in substitute without requiring IRQ reconfiguration. For level-triggered interrupts, software must explicitly clear the interrupt by writing to the corresponding bit in the HPET's General Interrupt Status Register to prevent continuous firing.[45][1]