【发布时间】:2018-02-09 00:37:56
【问题描述】:
如今,CPU 可以调整其频率以降低能耗。然而,许多进行高精度持续时间测量的方法并不直接依赖于测量时间,而是依赖于获取滴答计数。例如,RDTSC/RDTSCP 之类的汇编指令似乎访问了在每个时钟周期单调递增的滴答计数。或者 C 常量 CLOCKS_PER_SEC 这是...一个常量。对于频率可调的处理器,滴答计数和实际持续时间如何相关?以及如何从另一个推导出来?
【问题讨论】:
-
这是很久以前修复的,今天你的机器仍然有一个处理器出现这个问题的几率很低。我们从这里看不到它。 en.wikipedia.org/wiki/…
-
硬件有一个实时时钟,它与处理器时钟周期分开计数。在任何处理器速度可变的处理器中,实时和处理器周期之间没有恒定的相关性。
-
任何频率的 CPU 时钟都是重要的测量值。还有挂钟时间,所以你需要同时寻找。如果这些说明为您提供处理器时钟计数,那就太好了。现在找到一个可以准确测量挂钟时间的芯片(我说的是一般不是 x86 特定的,实际上你也是,因为你没有标记 cpu/arch)你所说的这些芯片通常由参考时钟驱动,比如 100Mhz GHz 速度是通过 pll 在内部完成的,希望设计人员提供基于参考时钟而不是倍频时钟的计数器/定时器。 (不太可能)
-
@EricPostpischil:现代 x86 确实如此,但一些早期的可变频率 CPU 没有恒定/不间断的 TSC,因此它不是可用的时间源。这两件事都有 CPUID 功能位:RDTSC 计算参考周期,并且当 CPU 内核时钟停止时它不会停止(睡眠 C 状态)。 Linux 更喜欢 RDTSC 作为时间源,但如果 CPU 不具备这两个特性,它就会回退到另一个源,比如 HPET。我的旧 Core2 系统使用 TSC 作为时钟源,但它可能是具有必要功能的第一代系统之一。
-
@PeterCordes:这就是为什么我说“硬件”有一个单独计数的实时时钟,而不是处理器。旧的东西在主板上有一个独立的时钟,有时是一个额外的选择。在此之前,您必须输入系统启动的时间。