CLOCK_TAI的时代是什么? [英] What is the epoch of CLOCK_TAI?

问题描述

自Linux内核版本3.10起，函数clock_gettime()现在接受CLOCK_TAI.

Since Linux kernel version 3.10, the function clock_gettime() now accept CLOCK_TAI.

我没有找到此时钟的详细描述.它的时代是什么?

I didn't manage to find a detailed description of this clock. What is its epoch ?

编辑1 :刚比较了Linux 3.19 OS上CLOCK_REALTIME和CLOCK_TAI的输出，它返回的值完全相同(1442582497)！ CLOCK_REALTIME是否在leap秒时递减?

EDIT 1: Just compared the output of CLOCK_REALTIME and CLOCK_TAI on my Linux 3.19 OS and it returns the exact same value (1442582497) !? Is CLOCK_REALTIME decremented at leap seconds ?

编辑2 :根据

EDIT 2: According to this article, the difference between CLOCK_TAI and the (badly named) CLOCK_REALTIME should be the number of leap seconds.

编辑3 :在编辑2中引用的文章中解释了同时出现CLOCK_TAI和CLOCK_REALTIME的原因.

EDIT 3: The reason CLOCK_TAI and CLOCK_REALTIME are the same time is explained in the article referenced in Edit 2. The emphasis is by me.

对于可能使用TAI时间而不是UTC的应用程序，内核提供了一个特殊的CLOCK_TAI时钟，该时钟确实包含leap秒，并且在leap秒后无需进行校正，从而避免了向后跳转的问题.时间完全.它的实现方式是时钟以相对于CLOCK_REALTIME的固定整数偏移量运行，当CLOCK_REALTIME时钟退回到leap秒时，原子偏移量将自动增加1.它是在Linux内核版本3.10中引入的，并且随RHEL7附带的内核一起提供. 请注意，与CLOCK_REALTIME的偏移量在启动时初始化为零，并且ntpd和chronyd均未将其默认设置为正确值(当前为35).在应用程序中切换至CLOCK_TAI当然需要对代码以及使用Unix时间表示的所有协议.

For applications where it would be possible to work with TAI time instead of UTC, the kernel provides a special CLOCK_TAI clock which does include leap seconds and doesn’t need to be corrected after leap second, avoiding the problem with backward jump in the time entirely. It’s implemented as a clock running at a fixed integral offset to CLOCK_REALTIME, which is atomically incremented by 1 when the CLOCK_REALTIME clock is stepped back on leap second. It was introduced in the Linux kernel version 3.10 and is available with the kernels shipped in RHEL7. Please note that the offset from CLOCK_REALTIME is initialized on boot to zero and neither ntpd nor chronyd set it by default to the correct value (currently 35). Switching to CLOCK_TAI in applications would of course require modifications to the code and possibly also all protocols that use the Unix representation of time.

编辑4 :在Ask Ubuntu上获得的答案阐明了所有内容.

Edit 4 : This answer obtained on Ask Ubuntu clarifies everything.

推荐答案

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

因此timeval/timespec的usec/nsec部分应该相同.

So the usec/nsec portion of a timeval/timespec should be identical.

CLOCK_MONOTONIC: Zeroed at boot.  

CLOCK_TAI = CLOCK_MONOTONIC + tai_mon_offset    

CLOCK_REALTIME(UTC) = CLOCK_TAI - tai_utc_offset  

但是由于性能方面的考虑(CLOCK_REALTIME是什么应用程序 锤子最多)，在Linux中，我们实际上将其结构如下:

But due to performance concerns (CLOCK_REALTIME is what applications hammer the most), in Linux we actually structure it as:

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)并且具有has秒文件，它将对其进行设置.它也可能能够从上游服务器获取它，但我无法进行验证.以root用户身份运行时，呼叫adjtimex()可以手动设置tai_offset.

Check by using adjtimex(timex tmx) and read the value. I think that ntpd will set it if it is new enough (>4.2.6) and has a leap second file. It may also be able to get it from upstream servers but I haven't been able to verify. The call adjtimex() can set tai_offset manually when run as root.

我的参考资料此处和此处

这篇关于CLOCK_TAI的时代是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！