通常，當一台機器完全失去連接時，ntpd 會錯過幾次輪詢，並將所有來源標記為理智失敗。這看起來很合乎邏輯。但我遇到過這樣一種情況：伺服器保持標記為當前時間來源，而其到達範圍變為 0。
伺服器部署在與目標機器相同的子網路中，提供非常低的延遲、偏移和抖動。這種情況是透過實體關閉連接來模擬的：只需從客戶端電腦上拔下電源線即可。我試圖重新創建這個，但從那時起，同一台機器總是在 5-6 次不成功的輪詢後很好地失去同步狀態。
真正的問題是：連線遺失時，到底是什麼決定了同步狀態？
答案1
RFC-1305中對到達暫存器有明確的解釋：
可達性暫存器左移一位，以零代替空出的位元。如果該暫存器的所有位元均為零，則呼叫清除程序來清除時脈濾波器並在必要時重新選擇同步來源。如果初始化過程未配置關聯，則取消關聯。
然而，RFC-1305 已被 RFC-5905 取代，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 到達的源視為當前時間源的狀態是可能的，但也是罕見的和暫時的。