CLOCK_MONOTONIC 与 CLOCK_MONOTONIC_RAW 截断值答案

【问题标题】：CLOCK_MONOTONIC vs CLOCK_MONOTONIC_RAW truncated valuesCLOCK_MONOTONIC 与 CLOCK_MONOTONIC_RAW 截断值
【发布时间】：2014-10-24 08:44:08
【问题描述】：

我正在编写一些需要纳秒级分辨率的测试代码。当我将 clock_gettime 与 CLOCK_MONOTONIC 一起使用时，我得到了一个我期望的值：3327.874384321。当我将 clock_gettime 与 CLOCK_MONOTONIC_RAW 一起使用时，我得到了一个我没想到的值：3327.875723000

我已经在循环中运行了这个，所有返回的值都具有“截断”的纳秒分辨率，000。

uname -a 的输出：Linux raspberrypi 3.12.22+ #691 PREEMPT Wed Jun 18 18:29:58 BST 2014 armv6l GNU/Linux

对正在发生的事情的想法？如何解决？我目前正在考虑禁用 NTP，以便我可以使用 CLOCK_MONOTONIC

【问题讨论】：

NTP 与此有什么关系？你为什么想要 RAW 时钟？
根据各种读数，CLOCK_MONOTONIC 可以通过 NTP 进行调整，从而产生任何样本被时钟调整污染的可能性。也许我误解了......这是一个stackoverflow参考：stackoverflow.com/questions/14270300/…
正如对该问题的回答所述，CLOCK_MONOTONIC 不反映设置时间或 NTP 调整的不连续性。相反，它的提前率只是被调整以校正硬件时钟频率相对于实时的不精确性。
R- 同意 NTP 更改速率（或频率），因此可能会扭曲结果，还是我仍然误解？
如果 NTP 改变速率，它只是让它更接近正确，而不是你的硬件出现偏差（时钟运行太快或太慢）。我不明白您为什么更喜欢不太正确的值。

标签： c linux raspberry-pi precision timing

【解决方案1】：

我认为您关于CLOCK_MONOTONIC_RAW 被“截断”的结论是错误的。相反，硬件时钟源的分辨率可能只有微秒。您在CLOCK_MONOTONIC 中看到的非零低位数字是因为硬件时钟源的时间戳正在缩放，根据通过adjtime/NTP 进行的调整，以纠正硬件时钟速率的不精确性，否则会使其漂移相对于实时。

要检验这个假设，您应该使用CLOCK_MONOTONIC 获取大量计时器样本，并在低位数字中寻找模式。我怀疑你会发现你所有的时间戳都相差若干纳秒的倍数接近但不完全 1000，例如可能是 995 或 1005 左右。

【讨论】：

我明白你在说什么，这就是我这样做的原因：clock_getres(CLOCK_MONOTONIC, &res); printf("单调 res: %lld.%.9ld\n", (long long)res.tv_sec, res.tv_nsec); clock_getres(CLOCK_MONOTONIC_RAW, &res); printf("单调原始分辨率：%lld.%.9ld\n", (long long)res.tv_sec, res.tv_nsec);单调 res：0.000000001 原始单调 res：0.000000001。两者都显示相同的值。 linux会躺在getres上吗？（抱歉格式不好）
另一种可能性（尽管没有记录在案）是CLOCK_MONOTONIC_RAW 可能显示CLOCK_MONOTONIC_COARSE 的未调整值，而不是CLOCK_MONOTONIC。您可能需要阅读详细资料才能确定。
为了获得真正的纳秒级分辨率，处理器必须运行 >1GHz 是否准确？我们是否可以说，由于 Raspberry Pi 仅运行在 700 MHz 左右，它不可能有纳秒级分辨率？
@Nick：不，那不是真的。时钟可以来自独立于 cpu 时钟的源，在这种情况下，它可以具有更高的分辨率。您可能无法经常对其进行采样以查看完整分辨率，但在 700 MHz 时内核仍需要报告 1ns 作为分辨率，因为无法报告 1.4ns。