挂钟时间通常由系统 RTC 提供。这主要只提供毫秒范围的时间,并且通常具有 10-20 毫秒的粒度。然而,通常报告gettimeofday()的分辨率/粒度在几微秒范围内。我假设微秒粒度必须取自不同的来源。
gettimeofday() 的微秒级分辨率/粒度是如何实现的?
当精确到毫秒的部分取自 RTC,而微秒取自不同的硬件时,就会出现两个源的定相问题。这两个来源必须以synchronized
某种方式存在。
这两个源之间的同步/定相是如何完成的?
编辑:根据我在 amdn 提供的链接中阅读的内容,特别是以下英特尔链接,我将在此处添加一个问题:
是否gettimeofday()
提供微秒级的分辨率/粒度?
编辑 2:用更多阅读结果总结 amdns答案:
Linux 仅在启动时使用实时时钟 (RTC) 与更高分辨率的计数器同步,例如时间戳计数器 (TSC)。启动后gettimeofday()
返回一个时间,该时间完全基于 TSC 值和此计数器的频率。frequency
通过将系统时间与外部时间源进行比较来校正/校准TSC 的初始值。调整由adjtimex()函数完成/配置。内核运行锁相环以确保时间结果是单调一致的。
这样可以说gettimeofday()
具有微秒级的分辨率。考虑到更现代的时间戳计数器在 GHz 范围内运行,可获得的分辨率可能在纳秒范围内。因此,这个有意义的评论
/**
407 * do_gettimeofday - Returns the time of day in a timeval
408 * @tv: pointer to the timeval to be set
409 *
410 * NOTE: Users should be converted to using getnstimeofday()
411 */
可以在Linux/kernel/time/timekeeping.c中找到。这表明以后可能会有更高分辨率的功能可用。现在getnstimeofday()
仅在内核空间中可用。
但是,查看所有涉及的代码以使其正确,显示出很多关于不确定性的评论。有可能获得微秒级的分辨率。该函数gettimeofday()
甚至可以在微秒范围内显示粒度。但是:drift
由于无法准确校正 TSC 频率,因此对其准确性存在严重疑问。此外,在 Linux 中处理此问题的代码的复杂性暗示着要正确处理它实际上太难了。这是特别的,但不仅仅是由于 Linux 应该在其上运行的大量硬件平台造成的。
结果: gettimeofday()
返回具有微秒粒度的单调时间,但它提供的时间几乎永远不会one microsecond
与任何其他时间源相匹配。