挂钟时间通常由系统RTC提供。这主要仅提供时间到毫秒范围，并且通常具有10到20毫秒的粒度。但是，通常报告说gettimeofday（）的分辨率/粒度在几微秒的范围内。我假设微秒粒度必须来自其他来源。

如何实现gettimeofday（）的微秒分辨率/粒度？

当从RTC提取到毫秒以下的部分并且从不同的硬件获取微秒时，会出现两个源的相位调整问题。这两个来源必须是synchronized某种方式。

这两个源之间的同步/定相如何完成？

编辑： 根据我在amdn提供的链接中阅读的内容，尤其是以下Intel链接，我会在这里添加一个问题：

是否gettimeofday()可以在微秒范围内提供分辨率/粒度？

编辑2： 使用更多阅读结果总结amdns 答案：

Linux仅在引导时使用实时时钟（RTC）与更高分辨率的计数器ig
Timestampcounter（TSC）进行同步。引导后，gettimeofday()将返回一个完全基于TSC值和该计数器频率的时间。frequency通过将系统时间与外部时间源进行比较，可以对TSC的初始值进行校正/校准。调整由adjtimex（）函数完成/配置。内核运行一个锁相环，以确保时间结果是单调且一致的。

这样可以说gettimeofday()具有微秒的分辨率。考虑到更现代的Timestampcounter在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频率的准确度存在严重质疑，因为TSC频率的准确度无法得到校正。同样，在Linux内部处理此问题的代码的复杂性也暗示着人们相信，实际上很难正确地做到这一点。这是特别的，但并非仅由应该运行Linux的大量硬件平台引起。

结果： gettimeofday()以微秒粒度返回单调时间，但它提供的时间几乎one microsecond与任何其他时间源都没有相位。