我的 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

/etc/ntpd.conf內容：

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

/etc/rc.conf.local內容：

nsd_flags=
ntpd_flags=-s
unbound_flags=
dhcpd_flags=vmx0

uname -a輸出：

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

我正在使用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

同樣在這裡，從底部向上幾行顯示“時鐘現已同步”，但仍然落後約 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

開始/停止等是我測試/嘗試的東西。

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。1 這比 UTC 早 26 秒，很快就會變成 27 秒。

眾所周知，Google時間源不計算閏秒。他們使用塗抹將未計算的額外秒的值分散到一整天，這意味著每年最多兩天Google秒不是統一的長度，並且與 SI 秒的長度不同。

rdate需要-c選項告訴它您的時間源不計算閏秒，並且您需要使用假設您的核心時鐘在 TAI-10 中執行的奧爾森“正確”時區。（“正確的”時區和計算 TAI 而不是 UTC 的核心時鐘有其優勢。）

具有諷刺意味的是，由於您也根據日誌使用中歐時間，因此 OpenBSD常見問題中給出的範例設置正是適合您的設置。因此，請閱讀 OpenBSD 文件並按照說明進行操作。

或者：如果您想在 UTC 而不是 TAI-10 中執行，請使用“posix”時區。

1 這是一個稍微簡化的解釋，它涉及一個常用的 UTC 追溯定義，並忽略了這樣一個事實，即 1972 年之前使用的 UT 秒是可變長度的，用於與 TAI 進行轉換的大型表驅動算法。但這超出了這個答案的範圍。1972年之前的情況非常可怕。有些人想取消 UTC 及其閏秒系統和 SI 秒長度，並將其帶回來。他們……被誤導了。

進一步閱讀

• “為什麼我的時鐘差了二十幾秒？ ”。OpenBSD常見問題。
• rdate. OpenBSD 6.0 手冊。
• 克里斯托弗·帕斯科 (2011-09-15)。 時間、技術和跳秒。Google。
• 佩里·洛里爾 (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

引用自：https://unix.stackexchange.com/questions/327361