4

从 Linux 内核版本 3.10 开始，该功能clock_gettime()现在接受CLOCK_TAI.

我没能找到这个时钟的详细描述。它的时代是什么？

编辑 1：刚刚比较了我的 Linux 3.19 操作系统上的 CLOCK_REALTIME 和 CLOCK_TAI 的输出，它返回完全相同的值（1442582497）！？CLOCK_REALTIME 是否在闰秒减少？

编辑 2：根据这篇文章， CLOCK_TAI 和（名字不好的） CLOCK_REALTIME 之间的区别应该是闰秒数。

编辑 3：编辑 2 中引用的文章解释了原因CLOCK_TAI和CLOCK_REALTIME时间相同。重点是我。

对于可以使用 TAI 时间而不是 UTC 的应用程序，内核提供了一个特殊的 CLOCK_TAI 时钟，它确实包括闰秒并且不需要在闰秒之后进行校正，从而完全避免了时间向后跳跃的问题. 它被实现为以相对于 CLOCK_REALTIME 的固定积分偏移量运行的时钟，当 CLOCK_REALTIME 时钟在闰秒后退时，该时钟以原子方式递增 1。它是在 Linux 内核版本 3.10 中引入的，并且随 RHEL7 中的内核一起提供。请注意，CLOCK_REALTIME 的偏移量在启动时被初始化为零，并且 ntpd 和 chronyd 都没有将其默认设置为正确的值（当前为 35）。在应用程序中切换到 CLOCK_TAI 当然需要修改代码，可能还需要修改所有使用 Unix 时间表示的协议。

编辑 4：在 Ask Ubuntu 上获得的这个答案澄清了一切。

4

1 回答 1

5 
CLOCK_TAI is basically designed as CLOCK_REALTIME(UTC) + tai_offset.

所以 timeval/timespec 的 usec/nsec 部分应该是相同的。

CLOCK_MONOTONIC: Zeroed at boot.  

CLOCK_TAI = CLOCK_MONOTONIC + tai_mon_offset    

CLOCK_REALTIME(UTC) = CLOCK_TAI - tai_utc_offset

但是由于性能问题（CLOCK_REALTIME 是应用程序最受打击的），在 Linux 中，我们实际上将其构造为：

CLOCK_REALTIME: Initialized at boot from RTC  
CLOCK_MONOTONIC: CLOCK_REALTIME - wall_to_monotonic  
CLOCK_TAI: CLOCK_REALTIME + tai_offset

所以CLOCK_REALTIME and CLOCK_TAI return the same because the kernel parameter tai_offset is zero.

通过使用检查adjtimex(timex tmx)并读取该值。我认为ntpd如果它足够新（>4.2.6）并且有闰秒文件，它将设置它。它也可能能够从上游服务器获取它，但我无法验证。以 root 身份运行时adjtimex()可以手动设置调用。tai_offset

我在这里和这里的参考

于 2015-09-20T01:52:32.130 回答