给定一个具有恒定 TSC的 x86，这对于测量实时很有用，如何使用 Linux 在启动时计算的 TSC 校准因子在TSC 参考周期的“单位”和正常的人类实时单位（如纳秒）之间进行转换?
CLOCK_MONOTONIC也就是说，当然可以通过在某个间隔的两端进行 TSC 和时钟测量（例如，用在内部使用 TSC 来帮助计时。
例如，您可以使用以下命令查看内核的结果dmesg | grep tsc：
[ 0.000000] tsc: PIT calibration matches HPET. 2 loops
[ 0.000000] tsc: Detected 3191.922 MHz processor
[ 1.733060] tsc: Refined TSC clocksource calibration: 3192.007 MHz
在更糟糕的情况下，我想你可以尝试dmesg在运行时 grep 结果，但坦率地说，这看起来很糟糕，脆弱和各种糟糕的0。
使用内核确定的校准时间的优点有很多：
- 您不必自己编写 TSC 校准例程，而且您可以确定 Linux 是同类最佳的。
- 当新内核使用您现有的二进制文件出现时，您会自动在 TSC 校准中采用新技术（例如，最近芯片开始使用
cpuid叶子 0x15 宣传其 TSC 频率，因此并不总是需要校准）。 - TSC 校准不会减慢您的启动速度。
- 您在每次运行进程时使用相同的 TSC 值（至少在重新启动之前）。
- 您的 TSC 频率在某种程度上与操作系统计时功能使用的 TSC 频率“一致”，例如
gettimeofdayandclock_gettime1。 - 内核能够在启动时很早就在内核模式下进行 TSC 校准，不受中断和其他进程的影响，并且能够访问底层硬件定时器方向作为其校准源。
但这并不全是肉汁，使用 Linux 的 TSC 校准的一些缺点包括：
- 它不会在每个 Linux 安装（例如，可能不使用 tsc 时钟源的那些）或其他操作系统上都有效，因此您可能仍然无法编写回退校准方法。
- 有理由相信“最近”的校准可能比旧的校准更准确，尤其是在启动后立即进行的校准：晶体行为可能会发生变化，尤其是随着温度的变化，因此您可以通过这样做获得更准确的频率手动靠近您将使用它的位置。
0例如：系统可能尚未dmesg安装，您可能无法以普通用户身份运行它，累积的输出可能已经回绕，因此这些行不再存在，您的 grep 可能会出现误报，内核消息是英文散文，可能会发生变化，可能很难启动子流程等。
1这是否重要有些争议 - 但如果您将rdtsc调用与也使用操作系统计时的代码混合，它可能会提高精度。