ntpd 自身無法正確更新漂移
我正在使用
ntpsecDebian 不穩定。在我的日誌中，我看到了以下內容：Mai 22 11:48:34 services ntpd[13428]: CLOCK: time stepped by 1.442261 Mai 22 11:55:06 services ntpd[13428]: CLOCK: time stepped by 1.524066 Mai 22 12:03:00 services ntpd[13428]: CLOCK: time stepped by 1.702944 Mai 22 12:08:34 services ntpd[13428]: CLOCK: time stepped by 1.517894 Mai 22 12:17:38 services ntpd[13428]: CLOCK: time stepped by 1.434055 Mai 22 12:24:07 services ntpd[13428]: CLOCK: time stepped by 1.084220 Mai 22 12:32:29 services ntpd[13428]: CLOCK: time stepped by 1.562280 Mai 22 12:38:38 services ntpd[13428]: CLOCK: time stepped by 1.211420 Mai 22 12:43:49 services ntpd[13428]: CLOCK: time stepped by 1.185642 Mai 22 12:48:58 services ntpd[13428]: CLOCK: time stepped by 0.796154 Mai 22 12:54:43 services ntpd[13428]: CLOCK: time stepped by 1.331323 Mai 22 13:00:21 services ntpd[13428]: CLOCK: time stepped by 0.849190這不僅僅是今天，它持續了好幾天。顯然，
ntpd沒有正確修復系統時鐘漂移。/var/lib/ntpsec/ntp.drift裡面總是有：500.000000我現在嘗試過的：
- 禁用 CONFIG_RTC_SYSTOHC，因此核心不會自動更新 RTC。幾個小時後，我跑去
hwclock -w --update-drift讀取 RTC 時至少獲得了更好的準確性。它將漂移因子設置為 0.78 秒/天。- 在那之後，我跑去
adjtimexconfig修復系統時鐘（ntpd應該做的事情）。它說：Comparing clocks (this will take 70 sec)...done. Adjusting system time by 275,531 sec/day to agree with CMOS clock...done.結果似乎是現在
ntpd必須減少很多時間：Mai 22 14:24:20 services ntpd[13428]: CLOCK: time stepped by 0.234963 Mai 22 14:30:30 services ntpd[13428]: CLOCK: time stepped by 0.145163好的。但是為什麼不自己
ntpd做呢？0.2sec/6min 似乎還是太不准確了，所以我想我得再重複幾次這個過程。有什麼建議麼？
出於某種原因，您的作業系統時鐘非常不准確。通常會通過旋轉
ntpd來保持它在正確的時間，即告訴一個慢時鐘“加速”以使其趕上實時，只有當它實際上與現實同步時才調整時鐘的速度以匹配實時時間，如果時鐘太快，同樣會減慢時鐘。但是對於您的作業系統時鐘，這種調整似乎是不夠的：錯誤如此之大，以至於
ntpd必須採取逐步調整，基本上每隔幾分鐘就將系統時鐘重置為更正時間。如果您想要準確記錄數據庫等的時間，則應完全避免步進調整。您不應該對任何非零數量的步進調整感到滿意。幸運的是，誤差似乎總是在同一個方向，所以它可能是一個可以調整的系統誤差。
**注意：**如果這是一台虛擬機，時間漂移可能是由於虛擬主機執行在高負載下，以及從空閒虛擬機“竊取時間”來執行繁忙的虛擬機造成的。如果是這種情況，請先諮詢虛擬化主機管理員，了解修復計時的推薦方法：可能有一個“半虛擬化時鐘”選項，可以讓 VM 基本上使用主機的時鐘進行計時，或者主機推薦的其他解決方案作業系統/管理程序供應商。如果您嘗試使用 NTP 同步，請確保虛擬主機不會擺弄 VM 的時鐘：它是一個或另一個，而不是兩者！
請注意，這
hwclock -w --update-drift將通過將電池支持的 RTC 時鐘與作業系統時鐘進行比較來估計其漂移，在您的情況下，這已經被認為是非常不准確的。所以你將調整一個可能很好的時鐘來匹配一個已知的壞時鐘，這聽起來不是一個好主意。
adjtimexconfig另一方面，假設電池支持的 RTC 是正確的，並調整 OS 時鐘的參數以匹配它。如果您有權訪問已知良好的 NTP 時間源，則應改為使用adjtimex --host <NTP server>將作業系統時鐘直接與 NTP 伺服器進行比較（ntpd在您執行此操作時停止），然後用於adjtimex -p查看結果frequency和tick值。或者，您可以只使用
adjtimex -p查看frequency已設置的偏移值ntpd。ntpd只會調整frequency值；它根本不會觸及tick設置。如果您發現頻率偏移值一直到刻度的任一端 +/-32768000，則應
tick手動調整該值，然後重複該過程。（如果
frequency達到或接近最大正值，則該工具正在嘗試加速時鐘並且由於超出調整範圍而未能充分加速。要解決此問題，請增加該tick值。如果frequency達到或接近負值限制，減小tick值。）一旦你找到一個
tick讓頻率偏移值保持在相對接近刻度中間的值（例如，+/- 5000000 左右），那麼ntpd應該有更好的機會通過調整頻率偏移值來保持時鐘同步如所須。您應該手動編輯刻度值/etc/default/adjtimexconfig並確保adjtimex.service在啟動時成功執行：它在啟動之前執行ntpd，因此在ntpd開始充當它的“巡航控制”之前將作業系統時鐘設置為“正確的檔位”。一旦您控制了作業系統時鐘，
ntpd它將保持同步狀態（ntpq -np將在第一列中顯示一個星號）並且除了可能在啟動時一次之外沒有關於步進調整的日誌消息，那麼您可以使用hwclock -w --update-drift來估計RTC 時鐘的漂移率。最終結果應該是一個系統，無論它是否通電，都能保持盡可能合理的時間。