為什麼 NTP 認為我的伺服器不足？
我有一個嵌入式 Linux 設備通過 USB/Net 介面直接連接到我的 Windows 桌面。它基於飛思卡爾 iMX6 板，所以我相信時鐘硬體是 SNVS RTC。
在桌面上
192.0.0.10，我將 W32Time 作為 NTP 伺服器執行，並且嵌入式設備192.0.0.100（我認為）已正確配置為根據ntp.conf文件使用它：server 192.0.0.10 iburst minpoll 5 maxpoll 7 driftfile /data/ntp.drift restrict default nomodify nopeer noquery limited kod restrict 127.0.0.1 restrict [::1]連接性不是問題(a)，因為我可以在嵌入式設備上執行：
ntpdate -uq 192.0.0.10 ntpdate -ub 192.0.0.10這將成功查詢和更新時間。
但是，我發現應該保持同步的時鐘
ntpd漂移了很多。我大約在 18 小時前開始並同步ntpd，偏移量逐漸上升到大約 5 秒：remote refid st t when poll reach delay offset jitter ============================================================================== 192.0.0.10 192.168.0.4 4 u 31 32 377 1.452 4941.57 11.927在過去的幾個小時裡，它實際上已經開始恢復，但距離它應該是 3.2 秒還有 3.2 秒。無論如何，我不相信這僅僅是巧合，原因如下。
當我看到它持續上升時，我做了一些探勘。關聯命令的輸出
ntpq是（現在仍然是）：# ntpq -c as ind assid status conf reach auth condition last_event cnt =========================================================== 1 62876 9024 yes yes none reject reachable 2這似乎表明，儘管可以訪問，但由於某種原因正在過濾伺服器。根據狀態
9024（請參閱此處），它似乎可以通過“被丟棄為無效（TEST10-TEST13）”來解釋。所以，然後我去看看
ntpq那個關聯的變數：# ntpq -c rv 62876 associd=62876 status=9024 conf, reach, sel_reject, 2 events, reachable, srcadr=192.0.0.10, srcport=123, dstadr=192.0.0.100, dstport=123, leap=00, stratum=4, precision=-6, rootdelay=129.150, rootdisp=2193.741, refid=192.168.0.4, reftime=ddd30907.eff60ee5 Thu, Dec 7 2017 0:25:43.937, rec=ddd31287.4db24cd8 Thu, Dec 7 2017 1:06:15.303, reach=377, unreach=0, hmode=3, pmode=4, hpoll=5, ppoll=5, headway=21, flash=400 peer_dist, keyid=0, offset=3186.569, delay=1.446, dispersion=16.036, jitter=11.844, xleave=0.093, filtdelay= 1.45 1.42 1.41 1.47 1.44 1.43 1.44 1.48, filtoffset= 3186.57 3189.58 3192.08 3194.56 3197.13 3199.58 3202.57 3205.06, filtdisp= 15.63 16.12 16.60 17.08 17.58 18.06 18.54 19.03我看到該
flash變數設置為400，基於上面連結到的同一頁面，顯示0400/TEST11/peer_dist/peer distance exceeded.現在我認為這不是物理距離（客戶端和伺服器都在我的桌面上）或網路距離（兩個設備直接連接）。我能在網上找到的唯一有用的參考資料是在Google Groups上，其中一位 David Woolley 說：
超過距離意味著最壞情況往返時間引發的錯誤和自根伺服器上的最後一個有效時間（加上一些次要組件）以來假定的 15ppm 漂移的組合超過了 1 秒。
它通常發生在已同步一次但任其漂移的 w32time 伺服器上。如果伺服器處於孤立模式，並且太長時間沒有實時源，並且您沒有使用最新的孤立模式程式碼，也會發生這種情況。
不幸的是，我不知道如何計算“最壞情況下的往返時間引起的錯誤”，所以我不確定如何從這裡開始。我很確定我的桌面正在與公司時間伺服器同步（我的，以及其他一些桌面的時間似乎都非常接近），儘管我也不確定如何重點檢查。
所以，我的問題是，我可以從這裡去哪裡？我似乎無法從中獲得更多有用的資訊，
ntpq甚至ntpd -dd在前台執行似乎也無法弄清楚伺服器時間被拒絕的原因。任何幫助將不勝感激。
(a)正如 Windows 端的日誌進一步指出的那樣，啟用：
w32tm /debug /enable /file:C:\w32time.log /size:10000000 /entries:0-300並生產：
152281 02:06:57.1968483s - ListeningThread -- DataAvailEvent set for socket 1 (0.0.0.0:123) 152281 02:06:57.1973483s - ListeningThread -- response heard from 192.0.0.100:123 <- 192.0.0.10:123 152281 02:06:57.1973483s - /-- NTP Packet: 152281 02:06:57.1973483s - | LeapIndicator: 3 - not synchronized; VersionNumber: 4; Mode: 3 - Client; LiVnMode: 0xE3 152281 02:06:57.1973483s - | Stratum: 0 - unspecified or unavailable 152281 02:06:57.1973483s - | Poll Interval: 5 - 32s; Precision: -20 - 953.674ns per tick 152281 02:06:57.1973483s - | RootDelay: 0x0000.0000s - unspecified; RootDispersion: 0x0000.F1A0s - 0.943848s 152281 02:06:57.1973483s - | ReferenceClockIdentifier: 0x494E4954 - source name: "INIT" 152281 02:06:57.1973483s - | ReferenceTimestamp: 0x0000000000000000 - unspecified 152281 02:06:57.1973483s - | OriginateTimestamp: 0xDDD320A033087D7D - 13157085984199348300ns - 152281 02:06:24.1993483s 152281 02:06:57.1973483s - | ReceiveTimestamp: 0xDDD3209D4DB18BA5 - 13157085981303490400ns - 152281 02:06:21.3034904s 152281 02:06:57.1973483s - | TransmitTimestamp: 0xDDD320BE4D535D3F - 13157086014302053300ns - 152281 02:06:54.3020533s 152281 02:06:57.1973483s - >-- Non-packet info: 152281 02:06:57.1973483s - | DestinationTimestamp: 152281 02:06:57.1973483s - 0xDDD320C132856B0E152281 02:06:57.1973483s - - 13157086017197348300ns152281 02:06:57.1973483s - - 152281 02:06:57.1973483s 152281 02:06:57.1973483s - | RoundtripDelay: -562900ns (0s) 152281 02:06:57.1973483s - | LocalClockOffset: -2895576400ns - 0:02.895576400s 152281 02:06:57.1973483s - \-- 152281 02:06:57.1973483s - TransmitResponse: sent 0.0.0.0:123(192.0.0.10:123)->192.0.0.100:123更新評論“在過去的幾個小時裡，它實際上開始回來了”：它實際上又開始漂移了（目前為 3.7 秒），所以我認為這是一個巧合的想法似乎得到了支持。
您的客戶端拒絕與伺服器同步，因為它的“根分散”（伺服器自己估計其與“真實”時間的誤差，以及導致對等距離的變數之一）約為 2.2 秒，大於預設容差為一秒。
儘管最好調試伺服器並弄清楚為什麼它對自己的計時能力有如此糟糕的估計，但您可以通過
tos maxdist在 ntp.conf 中為該選項提供更大的值來強制客戶端與之同步。