什麼是 NTP 分散以及如何控制它？
我們在隔離網路上推出 Ubuntu 14.04 伺服器，執行 ntpd 4.2.6p5，配置為使用客戶提供的多個 NTP 伺服器（無法訪問 pool.ntp.org）。我們的啞終端客戶端設備執行舊版本的 BusyBox (1.00-rc2) 和Larry Doolittle 的ntpclient 2010。
這種設置多年來一直執行良好，但最近我們遇到了一個新客戶的障礙。
ntpdate-debian他們為我們提供了 5 個內部 NTP 伺服器地址，就 Linux 伺服器而言，這些地址本身似乎工作得很好。然而，在 BusyBox 方面，ntpclient抱怨“分散太高”。從調試輸出中，ntpclient從 NTP 伺服器獲取“1217163.1”，但它支持的最大值是絕對值（65536）。$ /usr/sbin/ntpclient -s -i 15 -h 10.17.162.250 -d Configuration: -c probe_count 1 -d (debug) 1 -g goodness 0 -h hostname 10.17.162.250 -i interval 15 -l live 0 -p local_port 0 -q min_delay 800.000000 -s set_clock 1 -x cross_check 1 Listening... Sending ... recvfrom packet of length 48 received Source: INET Port 123 host 10.17.162.250 LI=0 VN=3 Mode=4 Stratum=4 Poll=4 Precision=-20 Delay=60745.2 Dispersion=1346801.8 Refid=10.31.10.21 Reference 3668859928.942079 (sent) 3668859928.708371 Originate 3668859928.708371 Receive 3668859928.963271 Transmit 3668859928.963369 Our recv 3668859928.708371 Total elapsed: 0.00 Server stall: 93.09 Slop: -93.09 Skew: 255443.94 Frequency: 0 day second elapsed stall skew dispersion freq 42463 56728.708 rejected packet: abs(DISP)>65536這些都是同一個區域網路上的所有設備，所以坦率地說，我大吃一驚。甚至嚇壞了。
這是
ntpq -pnUbuntu 14.04 伺服器的輸出：user@host:~$ ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== 127.127.1.0 .LOCL. 10 l 1025 64 0 0.000 0.000 0.000 10.17.162.249 10.17.6.10 5 u 23 1024 37 0.865 1381.07 697.260 10.31.10.22 .LOCL. 1 u 1044 1024 17 29.586 -838.06 397.342 10.17.6.10 10.31.10.21 4 u 1065 1024 17 0.366 105.245 402.999 *10.31.10.21 132.246.11.238 3 u 5 1024 37 29.418 794.292 616.796 10.17.6.11 10.31.10.21 4 u 1038 1024 17 0.408 120.030 381.058我的問題是：
- 什麼是色散，什麼可以改變它的價值？
- 我可以執行哪些命令從 NTP 伺服器獲取更多詳細資訊？
- 錯誤可能出在 Ubuntu 伺服器端
ntp.conf嗎？那裡真的沒有什麼特別的。- 在這種情況下切換到chrony會改變什麼嗎？
我在這裡的答案中看到了一些混亂。對於初學者來說，
ntpclient至少在-s模式下，它並沒有充當完整的 NTP 客戶端，它只發送和接收一個數據包，因此沒有“收到的最後 8 個數據包”。它實際上根本沒有估計自己的分散。相反，它列印的值是伺服器返回的數據包中稱為“根離散度”（rootdisp）的值，它是該伺服器與正確時間之間的錯誤/變異數總量的估計值。計算方法非常簡單：每個 NTP 伺服器要麼從外部時鐘（例如無線電或 GPS 接收器）獲取時間，要麼從另一個 NTP 伺服器獲取時間。如果伺服器從外部時鐘獲取時間，則其根離散度是該時鐘的估計最大誤差。如果它從另一個 NTP 伺服器獲取時間，則其根分散是該伺服器的根分散加上它們之間的網路連結添加的分散。
這裡令人困惑的一點是，雖然 ntpq 和 chrony 以秒為單位顯示分散和根分散，這是人們習慣於查看的，但 ntpclient 以微秒顯示。無論如何，1217163 的值仍然很高。一個好的 NTP 伺服器可以在幾毫秒內知道時間；在幾十或幾百毫秒內出現一個壞的。你的告訴你，它的時間只能在 +/- 1.2 秒內被信任。
-x 0您實際上可以通過傳遞or-t選項（取決於 ntpclient 的版本）來讓 ntpclient 同步到該伺服器，這會禁用 NTP 健全性檢查。如果您只需要大致準確的時間（幾秒鐘內），那可能就足夠了。但是，ntpclient 拒絕同步到如此糟糕的伺服器是非常合理的。您ntpq在 ubuntu 機器上的輸出顯示其所有伺服器的抖動為數百毫秒，即使它們具有低延遲，這表明網路非常不可靠，所有伺服器合謀提供不穩定的時間，或者基本伺服器本身的計時問題。我還擔心伺服器 10.31.10.22 正在通告
LOCL（無紀律的本地時鐘）的 refid，但層數為 1。通常本地時鐘被偽造為層數 10，因此它僅用作最後的同步源以防止牛群分散。要麼 10.31.10.22 配置錯誤並為網路的其餘部分提供了糟糕的時間，要麼它被 NTP 控制之外的某些程序訓練為良好的時間，在這種情況下，錯誤配置只是它正在宣傳LOCLrefid；它應該被覆蓋到 egGPS或任何提供時間的東西。