高精度事件計時器（英語：High Precision Event Timer，縮寫HPET），也稱高精度事件定時器，它是個人電腦中使用的一種硬件計時器，由英特爾（Intel）與微軟共同開發，並自2005年以來已被納入晶片組。
| 此條目需要精通或熟悉相關主題的編者參與及協助編輯。 |
使用不支援硬件HPET的舊款作業系統的裝置只能使用舊型號計時裝置，例如可程式化間隔計時器（PIT）或實時時鐘（RTC）。當Windows XP配有最新的硬件抽象層（HAL）時，也可以使用處理器的時間戳控制器（TSC）或電源管理計時器（PMTIMER），從而與RTC一起提供作業系統的功能，這些功能在Windows Vista中由硬件HPET提供。
一個HPET晶片包含一個以至少10 MHz赫茲計數的64位元向上計數器（主計數器）和，和一組（至少三個，最多256個）比較器。比較器的位寬為32位元或64位元。HPET可通過以進階組態與電源介面（ACPI）發現的一個主記憶體對映I/O窗口來編程。現代PC中的HPET電路整合在南橋晶片中。[a]
當最低有效位等於64位元主計時器值的相應位時，每個比較器可以產生一個中斷。比較器可以進入單觸發模式或周期模式，至少有一個比較器支援周期模式，並且都支援單觸發模式。在單觸發模式下，當主計數器達到儲存在比較器暫存器中的值時，比較器會觸發一次中斷，而在周期模式下，中斷將以指定間隔生成。
比較器可以由作業系統驅動，例如為每個CPU的排程提供一個計時器，或者由應用程式操作。
HPET可以提供比RTC更高的解像度產生周期性中斷，並經常用於同步多媒體流、提供平滑播放，和減少使用其他時間戳計算（如基於x86 CPU的RDTSC指令）的使用需求。
HPET旨在補充和替換8254可程式化間隔定時器和RTC的周期性中斷功能。與這些較老計時器電路相比，HPET具有更高的頻率（至少10 MHz）和更寬的64位元計數器（也可以在32位元模式下驅動）。[1]
雖然8254和RTC可以類似HPET進入單觸發模式，但是設置過程非常慢，以致於它們的單觸發模式在實際應用中不會用於需要精確排程的任務。[2]相反，8254和RTC通常以非常小的時間間隔用於周期模式。例如，如果一個應用程式需要執行幾個短暫的時間（也許是等待），把定時器設定為1ms間隔的周期模式會更好，因為8254和RTC的設置成本太高（例如為了實現5ms的延時，設置和啟動定時器卻花費了1ms，造成精度不達標）。這樣的設定會導致每個毫秒都產生一次中斷，而應用程式的工作很可能並不如此頻繁。使用HPET可以避免額外的中斷，因為HPET單觸發計時器的設置成本小得多。
在HPET出現之前設計的作業系統不能使用HPET，因此將使用其他計時器裝置。較新的作業系統往往可以使用較新與較舊的計時器。一些硬件同時有較新與較舊的計時器。事實上，目前的南橋晶片大多數也都同時支援傳統的PIT、PIC、進階可程式化中斷控制器（APIC）和RTC裝置，無論作業系統是否使用，從而有助於非常現代的PC執行舊款作業系統。
已知下列作業系統無法使用HPET：Windows XP SP2[b]、 Windows Server 2003及更早的Windows版本，Linux內核2.6以前。[c]
已知下列作業系統可以使用HPET：Windows XP SP3、[d] Windows Server 2008、Windows Server 2008 R2、Windows Vista、 Windows 7、基於x86的OS X[3]、使用2.6或更高內核的Linux作業系統以及FreeBSD[4]。
Linux內核也可以使用HPET作為其時鐘源。Red Hat MRG第二版的文件指，TSC是首選時鐘源——因為它的開銷低很多，而HPET作為後備時鐘源。一個千萬次事件計數的基準測試顯示，TSC花費約0.6秒，而HPET花費略微超過12秒，ACPI電源管理計時器花費約24秒。[5]
HPET是一個持續向上計數計時器，而不是一個倒數到零並導致一個中斷然後客製化的單次觸發元件。因為HPET是比較實際計數器值是否大於或等於可程式化目標值，因此如果寫入晶片暫存器的比較值所指的目標時間已經錯過，中斷則被錯過。在此種情況下，不僅目標中斷被錯過，而且將遠遠落後（約232或264次）。在存在如系統管理模式（SMI）等執行時間沒有硬上限的不可封鎖中斷時，這種競爭危害需要在設置後對計時器進行耗時的重新檢查，並且難以完全避免。如果比較器的值不立即與計時器同步，而是延遲一至兩個周期（某些晶片組如此），則困難更為艱巨。[6]
除了上面提到的競爭條件，一篇VMware文件還列出了其他一些缺點：「規範未要求計時器特別精細，具有低飄移和快速讀取能力。遊戲盤典型實現在大約18 MHz上執行計時器，並且讀取HPET所需時間（1–2 μs）與讀取ACPI計時器花費的時間相差無幾。 Implementations have been observed in which the period register is off by 800 parts per million or more."[7]
在高度整合的舊款裝置上，BIOS經常不正確設置ACPI中的HPET，只能在Intel 8253模式中正確初始化它。如果ACPI沒有正確設置，作業系統則無法列出HPET。並且BIOS和作業系統開發者不會看到需要即時支援。所以HPET只能滿足系統的高速需求。如果HPET由BIOS在ACPI中正確設置，則首個HPET晶片的ACPI MMIO頁應該在0xFED00000，第二個HPET頁在0xFED80000。 Windows XP SP2「了解」HPET計時器（作為一個PNP0103識別碼的裝置出現）。當檢測到該裝置時，開始-設置-控制面板-系統-裝置管理器中「系統裝置」分支下將出現一個「高精度事件計時器」裝置。但該裝置無相應驅動程式，並且不會被使用。 With a Linux內核, 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.
