OpenBSD 6.0 ntpctl 显示“时钟同步”但落后约 26 秒

Question

OpenBSD 6.0 ntpctl 显示“时钟同步”但落后约 26 秒

我的 OpenBSD 主机正在运行 NTPD，但慢了 26 秒，尽管它说“时钟同步”：

user@host:~# ntpctl -sa
4/4 peers valid, clock synced, stratum 3

peer
   wt tl st  next  poll          offset       delay      jitter
216.239.35.0 time1.google.com
    1 10  2 1063s 1078s        -1.951ms   101.103ms     0.594ms
216.239.35.4 time2.google.com
 *  1 10  2  481s 1067s        -1.742ms   112.251ms     0.447ms
216.239.35.8 time3.google.com
    1 10  2  729s  991s        -1.472ms    11.454ms     0.169ms
216.239.35.12 time4.google.com
    1 10  2  830s 1051s        -2.203ms   268.285ms     8.564ms

Run Code Online (Sandbox Code Playgroud)

/etc/ntpd.conf 内容：

server time1.google.com
server time2.google.com
server time3.google.com
server time4.google.com

Run Code Online (Sandbox Code Playgroud)

/etc/rc.conf.local 内容：

nsd_flags=
ntpd_flags=-s
unbound_flags=
dhcpd_flags=vmx0

Run Code Online (Sandbox Code Playgroud)

uname -a 输出：

OpenBSD host.domain.xxx 6.0 GENERIC.MP#2319 amd64

Run Code Online (Sandbox Code Playgroud)

我正在使用Google 最近推出的时间服务器。我有几台Linux hostname 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux正确同步的Debian 机器 ( )。

更改后/etc/ntpd.conf，/etc/rc.conf.local我重新启动了NTPD，甚至重新启动了。它仍然落后。

我试过ntpd -s -d给出：

user@host:~# ntpd -s -d
ntp engine ready
reply from 216.239.35.8: offset -0.002133 delay 0.011241, next query 9s
set local clock to Thu Dec  1 16:50:01 CET 2016 (offset -0.002133s)
reply from 216.239.35.0: offset -0.001434 delay 0.099329, next query 8s
reply from 216.239.35.4: offset -0.001749 delay 0.109564, next query 8s
reply from 216.239.35.12: offset -0.001908 delay 0.263908, next query 9s
reply from 216.239.35.0: offset -0.000319 delay 0.101452, next query 7s
reply from 216.239.35.4: offset -0.000641 delay 0.111670, next query 9s
reply from 216.239.35.8: offset 0.000052 delay 0.011303, next query 8s
reply from 216.239.35.12: offset -0.000872 delay 0.266129, next query 8s
reply from 216.239.35.0: offset -0.000597 delay 0.101577, next query 5s
reply from 216.239.35.8: offset -0.000018 delay 0.011269, next query 6s
reply from 216.239.35.4: offset -0.000755 delay 0.111866, next query 5s
reply from 216.239.35.12: offset -0.000842 delay 0.265926, next query 6s
peer 216.239.35.0 now valid
reply from 216.239.35.0: offset -0.000587 delay 0.101456, next query 5s
peer 216.239.35.4 now valid
reply from 216.239.35.4: offset -0.005059 delay 0.120511, next query 6s
peer 216.239.35.8 now valid
reply from 216.239.35.8: offset 0.000012 delay 0.011377, next query 9s
peer 216.239.35.12 now valid
reply from 216.239.35.12: offset -0.000859 delay 0.266074, next query 8s
reply from 216.239.35.0: offset -0.000591 delay 0.101480, next query 5s
reply from 216.239.35.4: offset -0.000681 delay 0.111761, next query 8s
reply from 216.239.35.0: offset -0.000675 delay 0.101565, next query 6s
reply from 216.239.35.12: offset -0.000896 delay 0.266249, next query 9s
reply from 216.239.35.8: offset -0.000090 delay 0.011496, next query 6s
reply from 216.239.35.0: offset -0.000676 delay 0.101632, next query 33s
reply from 216.239.35.4: offset -0.000636 delay 0.111738, next query 7s
reply from 216.239.35.8: offset 0.000037 delay 0.011290, next query 9s
reply from 216.239.35.12: offset -0.000871 delay 0.266122, next query 8s
reply from 216.239.35.4: offset -0.000649 delay 0.111825, next query 31s
reply from 216.239.35.8: offset 0.000018 delay 0.011296, next query 32s
reply from 216.239.35.12: offset -0.000922 delay 0.266301, next query 30s
reply from 216.239.35.0: offset -0.000634 delay 0.101520, next query 32s
reply from 216.239.35.4: offset -0.000732 delay 0.111862, next query 30s
reply from 216.239.35.8: offset 0.000041 delay 0.011358, next query 32s
reply from 216.239.35.12: offset -0.000903 delay 0.266024, next query 31s
reply from 216.239.35.0: offset 0.001242 delay 0.101406, next query 34s
reply from 216.239.35.4: offset -0.000638 delay 0.115180, next query 33s
reply from 216.239.35.12: offset 0.000838 delay 0.266193, next query 34s
reply from 216.239.35.8: offset 0.001788 delay 0.011284, next query 34s
clock is now synced
reply from 216.239.35.0: offset -0.000130 delay 0.101597, next query 33s
reply from 216.239.35.4: offset -0.000103 delay 0.111680, next query 34s
reply from 216.239.35.8: offset 0.000554 delay 0.011275, next query 30s
reply from 216.239.35.12: offset -0.000391 delay 0.266116, next query 33s
reply from 216.239.35.0: offset -0.000070 delay 0.101481, next query 32s
reply from 216.239.35.4: offset -0.000163 delay 0.111739, next query 33s
reply from 216.239.35.8: offset 0.000451 delay 0.011480, next query 31s
reply from 216.239.35.12: offset -0.000396 delay 0.266210, next query 30s
^Cntp engine exiting
Terminating

Run Code Online (Sandbox Code Playgroud)

同样在这里，从底部向上几行它说“时钟现在已同步”，但仍然落后约 26 秒。已经过了一天，它和昨天一样多，所以它似乎并没有缓慢地修正（或者修正得非常缓慢）。

编辑：正如Rui F Ribeiro所指出的那样；我忘了提到这台机器是在 ESXi 6 主机上运行的 VM（来宾）。然而，上述 Debian 机器/访客在同一台主机上。我的逻辑是，既然它们似乎工作正常，OpenBSD 不应该有什么不同吗？

我可以做什么/尝试让我的 OpenBSD 正确同步？

编辑： 根据 Bink的要求，（来自 ntpd 的事件）/var/log/daemon内容：

Nov 21 00:06:05 <hostname> ntpd[7477]: adjusting clock frequency by 0.317142 to -14.304083ppm
Nov 22 02:29:01 <hostname> ntpd[7477]: adjusting clock frequency by 0.305442 to -13.998538ppm
Nov 22 15:27:20 <hostname> ntpd[7477]: adjusting clock frequency by -0.138739 to -14.137278ppm
Nov 23 07:42:51 <hostname> ntpd[7477]: adjusting clock frequency by -0.061709 to -14.198986ppm
Nov 23 15:37:42 <hostname> ntpd[7477]: adjusting clock frequency by -0.303711 to -14.502698ppm
Nov 24 01:57:52 <hostname> ntpd[7477]: adjusting clock frequency by 0.266837 to -14.235861ppm
Nov 24 15:28:31 <hostname> ntpd[7477]: adjusting clock frequency by -0.223563 to -14.459424ppm
Nov 25 05:13:04 <hostname> ntpd[7477]: adjusting clock frequency by -0.223494 to -14.682917ppm
Nov 25 18:10:03 <hostname> ntpd[7477]: adjusting clock frequency by -0.324446 to -15.007363ppm
Nov 26 08:20:06 <hostname> ntpd[7477]: adjusting clock frequency by 0.295603 to -14.711760ppm
Nov 26 20:49:23 <hostname> ntpd[7477]: adjusting clock frequency by 0.517934 to -14.193826ppm
Nov 27 07:56:01 <hostname> ntpd[7477]: adjusting clock frequency by -0.269159 to -14.462985ppm
Nov 27 21:58:31 <hostname> ntpd[7477]: adjusting clock frequency by 0.239882 to -14.223103ppm
Nov 28 07:36:25 <hostname> ntpd[7477]: adjusting clock frequency by -0.435059 to -14.658162ppm
Nov 28 16:34:59 <hostname> ntpd[7477]: adjusting clock frequency by -0.299615 to -14.957777ppm
Nov 29 09:26:36 <hostname> ntpd[7477]: adjusting clock frequency by 0.137505 to -14.820272ppm
Nov 30 14:31:15 <hostname> ntpd[7477]: adjusting clock frequency by -0.215574 to -14.991138ppm
Nov 30 18:27:39 <hostname> ntpd[26935]: ntp engine exiting
Nov 30 18:27:39 <hostname> ntpd[3531]: dispatch_imsg in main: pipe closed
Nov 30 18:27:39 <hostname> ntpd[7477]: Terminating
Nov 30 18:27:55 <hostname> ntpd[27795]: ntp engine ready
Nov 30 18:27:58 <hostname> ntpd[27795]: ntp engine exiting
Nov 30 18:27:58 <hostname> ntpd[30737]: dispatch_imsg in main: pipe closed
Nov 30 18:27:58 <hostname> ntpd[15335]: Terminating
Nov 30 18:27:58 <hostname> ntpd[49555]: ntp engine ready
Nov 30 18:28:21 <hostname> ntpd[49555]: peer 216.239.35.0 now valid
Nov 30 18:28:22 <hostname> ntpd[49555]: peer 216.239.35.4 now valid
Nov 30 18:28:23 <hostname> ntpd[49555]: peer 216.239.35.12 now valid
Nov 30 18:28:24 <hostname> ntpd[49555]: peer 216.239.35.8 now valid
Nov 30 18:30:25 <hostname> ntpd[49555]: clock is now synced
Nov 30 18:40:47 <hostname> ntpd[10865]: ntp engine ready
Nov 30 18:40:47 <hostname> ntpd[36747]: set local clock to Wed Nov 30 18:40:47 CET 2016 (offset 0.000113s)
Nov 30 18:41:07 <hostname> ntpd[10865]: peer 216.239.35.8 now valid
Nov 30 18:41:07 <hostname> ntpd[10865]: peer 216.239.35.4 now valid
Nov 30 18:41:08 <hostname> ntpd[10865]: peer 216.239.35.12 now valid
Nov 30 18:41:09 <hostname> ntpd[10865]: peer 216.239.35.0 now valid
Nov 30 18:44:08 <hostname> ntpd[10865]: clock is now synced
Nov 30 18:48:10 <hostname> ntpd[49555]: ntp engine exiting
Nov 30 18:48:10 <hostname> ntpd[44908]: dispatch_imsg in main: pipe closed
Nov 30 18:48:10 <hostname> ntpd[59920]: Terminating
Nov 30 18:48:10 <hostname> ntpd[57325]: ntp engine ready
Nov 30 18:48:11 <hostname> ntpd[4035]: set local clock to Wed Nov 30 18:48:11 CET 2016 (offset 0.000388s)
Nov 30 18:48:29 <hostname> ntpd[57325]: peer 216.239.35.8 now valid
Nov 30 18:48:32 <hostname> ntpd[57325]: peer 216.239.35.4 now valid
Nov 30 18:48:32 <hostname> ntpd[57325]: peer 216.239.35.0 now valid
Nov 30 18:48:33 <hostname> ntpd[57325]: peer 216.239.35.12 now valid
Nov 30 18:50:57 <hostname> ntpd[53395]: Terminating
Nov 30 18:50:57 <hostname> ntpd[57325]: ntp engine exiting
Nov 30 18:50:57 <hostname> ntpd[26288]: dispatch_imsg in main: pipe closed
Nov 30 18:50:57 <hostname> ntpd[50972]: ntp engine ready
Nov 30 18:50:57 <hostname> ntpd[71389]: set local clock to Wed Nov 30 18:50:57 CET 2016 (offset 0.000046s)
Nov 30 18:51:14 <hostname> ntpd[50972]: peer 216.239.35.0 now valid
Nov 30 18:51:19 <hostname> ntpd[50972]: peer 216.239.35.4 now valid
Nov 30 18:51:21 <hostname> ntpd[50972]: peer 216.239.35.12 now valid
Nov 30 18:51:23 <hostname> ntpd[50972]: peer 216.239.35.8 now valid
Nov 30 18:53:46 <hostname> ntpd[46409]: ntp engine ready
Nov 30 18:53:47 <hostname> ntpd[51869]: set local clock to Wed Nov 30 18:53:47 CET 2016 (offset 0.017304s)
Nov 30 18:54:05 <hostname> ntpd[46409]: peer 216.239.35.0 now valid
Nov 30 18:54:06 <hostname> ntpd[46409]: peer 216.239.35.4 now valid
Nov 30 18:54:08 <hostname> ntpd[46409]: peer 216.239.35.8 now valid
Nov 30 18:54:08 <hostname> ntpd[46409]: peer 216.239.35.12 now valid
Nov 30 18:57:13 <hostname> ntpd[46409]: clock is now synced
Nov 30 19:15:19 <hostname> ntpd[43240]: adjusting clock frequency by 0.420934 to -14.570066ppm
Nov 30 19:34:26 <hostname> ntpd[43240]: adjusting clock frequency by 0.080845 to -14.489222ppm
Nov 30 19:53:41 <hostname> ntpd[43240]: adjusting clock frequency by -0.092990 to -14.582212ppm
Dec  1 16:56:15 <hostname> ntpd[43240]: Terminating
Dec  1 16:56:15 <hostname> ntpd[46409]: ntp engine exiting
Dec  1 16:56:15 <hostname> ntpd[59696]: dispatch_imsg in main: pipe closed
Dec  1 16:56:15 <hostname> ntpd[61779]: ntp engine ready
Dec  1 16:56:15 <hostname> ntpd[64211]: set local clock to Thu Dec  1 16:56:15 CET 2016 (offset 0.000150s)
Dec  1 16:56:16 <hostname> ntpd[61779]: ntp engine exiting
Dec  1 16:56:16 <hostname> ntpd[76241]: Terminating
Dec  1 16:56:16 <hostname> ntpd[48763]: dispatch_imsg in main: pipe closed
Dec  1 16:56:16 <hostname> ntpd[19408]: ntp engine ready
Dec  1 16:56:16 <hostname> ntpd[89788]: set local clock to Thu Dec  1 16:56:16 CET 2016 (offset 0.000336s)
Dec  1 16:56:35 <hostname> ntpd[19408]: peer 216.239.35.8 now valid
Dec  1 16:56:36 <hostname> ntpd[19408]: peer 216.239.35.12 now valid
Dec  1 16:56:38 <hostname> ntpd[19408]: peer 216.239.35.4 now valid
Dec  1 16:56:38 <hostname> ntpd[19408]: peer 216.239.35.0 now valid
Dec  1 17:00:49 <hostname> ntpd[19408]: clock is now synced
Dec  1 17:22:51 <hostname> ntpd[68037]: adjusting clock frequency by -0.076636 to -14.641308ppm

Run Code Online (Sandbox Code Playgroud)

开始/停止等是我测试/尝试的东西。

Answer 1

Jde*_*eBP 14

OpenBSD 和您的虚拟机工作正常；您误用了 Google 时间源。

这在 OpenBSD常见问题和手册页中。

您正在同步到发布 UTC 时间的时间源。但默认情况下rdate假定您的时间源发布 TAI-10 时间。TAI 是所有 SI 秒的严格统一递增计数，始终为每分钟 60 秒，目前比 UTC 早 36 秒，有时会打折所谓的“闰秒”。（更准确地说：它打折正闰秒；但实际上还没有负闰秒。）它将在 2016 年 12 月 31 日 23:59:60 UTC 比 UTC 提前 37 秒，闰秒即将到来在这个月底。

使用 TAI 而不是 UTC 的系统实际上倾向于使用更准确的称为 TAI-10 的东西，即 TAI 计数向未来移动 10，以便它与 1970-01-01 00:00:00 UTC 对齐，也称为如 1969-12-31 23:59:50 TAI，与 1970-01-01 00:00:00 TAI-10。¹ 这比 UTC 早 26 秒，很快就会变成 27 秒。

众所周知，谷歌时间源不计算闰秒。他们使用涂抹将未计算的额外秒的值传播到一整天，这意味着每年最多有两天谷歌秒不是统一的长度，并且与 SI 秒的长度不同。

rdate需要-c选择告诉它您的时间源不计算闰秒，并且您需要使用奥尔森“正确”时区，假设您的内核时钟在 TAI-10 中运行。（“正确”时区和计算 TAI 而不是 UTC 的内核时钟有其优势。）

具有讽刺意味的是，由于您也在根据您的日志使用中欧时间，因此 OpenBSD常见问题中给出的示例设置正是适合您的设置。因此，请阅读 OpenBSD doco 并按照说明进行操作。

或者：如果您想以 UTC 而不是 TAI-10 运行，请使用“posix”时区。

^{1 这是一个稍微简化的解释，涉及 UTC 的常用追溯定义，并忽略了这样一个事实，即 1972 年之前使用的 UT 秒是可变长度的，使用大型表驱动算法来转换为/从 TAI。但这超出了本答案的范围。1972 年之前的情况是可怕的。有些人想要废除 UTC 及其闰秒系统和 SI 秒长度，并将其带回来。他们……被误导了。}

进一步阅读

“为什么我的时钟差了二十几秒？ ”。OpenBSD常见问题。
rdate. OpenBSD 6.0 手册。
克里斯托弗·帕斯科 (2011-09-15)。 时间、技术和闰秒。谷歌。
佩里·洛里尔 (2015-07-01)。 timeX.google.com提供非标准时间。#437. systemd 错误跟踪器。
丹尼尔·J·伯恩斯坦。UTC、TAI 和 UNIX 时间。cr.yp.to.
大卫·马多尔 (2010-12-27)。“ TAI?10 设置”。Unix 飞跃秒杀。
https://unix.stackexchange.com/a/294715/5132

归档时间：	8 年，9 月前
查看次数：	3322 次
最近记录：	8 年，9 月前