NTP 同步無法到達
通常，當機器完全失去連接時，ntpd 會錯過幾次輪詢並將所有來源標記為故障。這似乎很合乎邏輯。但是我遇到了一種情況，即伺服器在其範圍變為 0 時仍標記為目前時間源。
伺服器部署在與目標機器相同的子網中，提供非常低的延遲、偏移和抖動。這種情況是通過物理關閉連接來模擬的：只需從客戶端機器上拔下電源線。我試圖重新創建它，但從那時起，同一台機器總是在 5-6 次不成功的輪詢後很好地失去同步狀態。
真正的問題是：當連接失去時，究竟是什麼決定了同步狀態？
RFC-1305 中有關於到達寄存器的明確解釋：
可達性寄存器向左移動一位，用零替換空出的位。如果該寄存器的所有位都為零，則呼叫清除過程以清除時鐘過濾器並在必要時重新選擇同步源。如果初始化過程未配置關聯，則解除關聯。
Howewer RFC-1305 已被 RFC-5905 淘汰，這並不是決定性的：
接下來，使用第 13 節中描述的輪詢過程中的 8 位 p.reach 移位寄存器來判斷伺服器是否可達以及數據是否新鮮。發送數據包時，寄存器左移一位，最右邊的位設置為零。當有效數據包到達時，最右邊的位設置為 1。如果寄存器包含任何非零位，則認為伺服器可達；否則，它是無法訪問的。
第 13 節中沒有提到明確的過程。但看起來一個無法訪問的對等點在某些時候應該會失去其同步狀態。
我已經設法在達到 0 的情況下重新創建同步狀態，以確保它很少見且根本不是永久性的。它需要在伺服器配置中禁用“突發”並在同步後立即斷開連接。
remote refid st t when poll reach delay offset jitter ============================================================================== 91.198.10.4 194.190.168.1 2 u 20 64 177 51.137 -2.192 11.049 192.168.1.1 193.67.79.202 2 u 65 64 77 0.459 -1.818 0.922 remote refid st t when poll reach delay offset jitter ============================================================================== *91.198.10.4 194.190.168.1 2 u 21 64 177 51.137 -2.192 11.049 +192.168.1.1 193.67.79.202 2 u - 64 177 0.449 -3.192 1.828範圍是 177，即二進制 01111111。所以需要 7 次輪詢來建立同步。
然後在這個位置失去同步：
remote refid st t when poll reach delay offset jitter ============================================================================== +91.198.10.4 194.190.168.1 2 u 574 64 0 63.846 -9.652 0.756 *192.168.1.1 193.67.79.202 2 u 553 64 0 0.449 -3.192 0.505 remote refid st t when poll reach delay offset jitter ============================================================================== 91.198.10.4 194.190.168.1 2 u 575 64 0 69.871 -10.409 0.002 192.168.1.1 193.67.79.202 2 u 554 64 0 0.449 -3.192 0.505當數字有點奇怪時，因為 64*9 = 576 而不是 575，但我想，表示可能是 1 秒不准確。考慮到這一點，需要 9 次不成功的輪詢才能打破同步狀態。
因此，從理論和實踐兩方面考慮，0 範圍的源可能被認為是目前時間源的狀態似乎是可能的，但也是罕見的和暫時的。