高精度事件计时器
此条目需要精通或熟悉相关主题的编者参与及协助编辑。 |
此条目目前正依照其他维基百科上的内容进行翻译。 (2017年4月10日) |
此条目翻译自其他语言维基百科,需要相关领域的编者协助校对翻译。 |
高精度事件计时器(英语: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.
参考资料
编辑- ^ Intel Corporation, IA-PC HPET (High Precision Event Timers) Specification (revision 1.0a) (PDF), October 2004 [2012-06-15], (原始内容存档 (PDF)于2013-03-10)
- ^ Guidelines For Providing Multimedia Timer Support, 2002-09-20 [2009-11-10], (原始内容存档于2009-08-15)
- ^ HPET Support - The BIOS Optimization Guide. Tech ARP. 2017-09-19 [2021-05-10]. (原始内容存档于2021-05-10) (美国英语).
- ^ FreeBSD Man Pages: hpet(4). [2017-04-10]. (原始内容存档于2017-02-21).
- ^ Chapter 15. Timestamping. Access.redhat.com. [2014-02-14]. (原始内容存档于2016-05-07).
- ^ Thomas Gleixner, x86: hpet: Work around hardware stupidity Archive.is的存档,存档日期2012-07-09, commit merged for Linux kernel 2.6.36-rc5
- ^ Timekeeping in VMware Virtual Machines (for VMware vSphere 5.0, Workstation 8.0, Fusion 4.0) (页面存档备份,存于互联网档案馆), page 9