Linux 環境下 NTP 精確度的極限 （★
100 分）
作者詳細探討了在 Linux 環境下利用 NTP（Network Time Protocol，網路時間協定）及多個 GPS（全球衛星定位系統，Global Positioning System，泛指 GNSS 衛星導航系統）來源進行時間同步的極限與挑戰。他建立了一套測試環境，包括 8 台伺服器、5 個 GPS 時源，並使用 Chrony 進行同步，目標是在分散式系統的記錄中維持一致且可信的時間戳記。雖然理想狀態下希望達到 1 微秒（μs）以內，甚至 10 奈秒（ns）的精度，但實際結果顯示在真實環境中難以做到。GPS 本身在不同接收器間可能有數十至數百奈秒的偏移，網路拓樸的多路徑轉送會帶來 200–300 ns 的誤差，而不同品牌的網卡與驅動程式也會明顯影響結果。加上 Linux 系統的隨機暫停（尤其出現在廉價硬體）會造成微秒等級的延遲，使得超高精度同步變得困難。整體而言，作者能在網路內的測試系統間達成 200–500 ns 的同步誤差，最終仍在 1 μs 以內，遠比最初設定的 10 μs 目標更好。
文章指出，Chrony 所報告的偏移值固然有參考價值，但並不是絕對準確，必須透過示波器等硬體工具進一步交叉驗證。作者在觀測中發現，不同 GPS 模組輸出的 PPS（每秒脈衝信號）彼此之間會隨時間漂移，部分誤差來自天線纜線長度不一致。此外，網路延遲假設的對稱性並不總是符合事實，多路徑選擇導致伺服器之間即便相鄰，也會出現一組認為 `ntp1` 快、一組認為 `ntp2` 快的情況。透過在各個時源進行手動補償與調整偏移，作者能將來源間的誤差縮小，但 jitter（抖動）仍會限制最終精度。測試顯示桌機搭配高品質 GNSS 模組與 Intel E810 網卡在 jitter 表現上最佳，而基於 Raspberry Pi 的方案則較差。
在 Hacker News 的討論中，部分留言者補充了技術細節。例如，有人指出 GPS 接收器本身應該支援 sawtooth correction（鋸齒修正），可用來抵消 PPS 與實際 GPS 時間的差異，否則會留下主要的抖動來源。另有人提醒要將 GPS 模組設置在靜止模式並進行測站定位，才能長期達成約 10 ns 的穩定度。此外，許多讀者討論作者雖展示 Chrony 的高精確度，但時間同步本質上還受到測試方法與硬體差異影響，若要進一步提升準確度應考慮使用 PTP（Precision Time Protocol，精確時間協定），尤其搭配支援硬體時間戳記的網卡時，可達 100 ns 以內的精度，甚至更好。
至於這種高精度同步的實際需求，有人提到包括高頻交易對時間戳的要求、行動基地台之間的精確同步、跨地理位置的無線電接收機三角定位、Google Spanner 等分散式資料庫的事件排序，甚至是影音製作系統避免影格累積誤差。其他人則強調真正目標是「一致性」而非絕對的「準確性」，只要能確保所有節點在相對上對齊，即使不與 GNSS 完全一致，也足以支撐多數分散式應用。
總結而言，這篇文章展示了在 Linux 環境中挑戰 NTP 精度的過程與限制：GPS 源頭、網路不對稱傳輸、硬體品質與作業系統本身都會影響結果。雖然無法達成理論上的 10 ns 精度，但在實務上已能在 500 ns 以內完成對齊，對於大多數分散式系統應用來說已經相當可靠。討論則進一步指出 PTP、硬體修正與專業應用場景，說明當代網路時間同步在理論與實務間的落差。
👥
25 則討論、評論 💬
https://news.ycombinator.com/item?id=45021078