NTP 同期が不安定になる原因は何でしょうか?

NTP 同期が不安定になる原因は何でしょうか?

Ubuntu 10.04 システムで、次のような奇妙な NTP 同期イベントに気付きました。

Jul  3 02:19:51 hst ntpd[1432]: no servers reachable
Jul  3 02:36:55 hst ntpd[1432]: synchronized to 91.189.94.4, stratum 2
Jul  3 02:53:48 hst ntpd[1432]: time reset -10.407942 s
Jul  3 02:53:48 hst ntpd[1432]: kernel time sync status change 6001
Jul  3 02:53:48 hst dovecot: dovecot: Fatal: Time just moved backwards by 10 seconds. This might cause a lot of problems, so I'll just kill myself now. http://wiki.dovecot.org/TimeMovedBackwards
Jul  3 02:58:37 hst ntpd[1432]: synchronized to 91.189.94.4, stratum 2
Jul  3 02:58:37 hst ntpd[1432]: kernel time sync status change 2001
Jul  3 03:08:15 hst ntpd[1432]: no servers reachable
Jul  3 03:16:49 hst ntpd[1432]: synchronized to 91.189.94.4, stratum 2
Jul  3 03:17:01 hst CRON[28221]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Jul  3 03:18:04 hst ntpd[1432]: time reset +10.403648 s
Jul  3 03:22:41 hst ntpd[1432]: synchronized to 91.189.94.4, stratum 2

91.189.94.4 europium.canonical.com で、唯一のサーバー行は次のとおりntp.confです。

server ntp.ubuntu.com

2:36 の更新は 25 分後にキャンセルされるため、かなり偽物と思われます。

これにはどのような理由が考えられますか?

思いつくのは:

  • リモートNTPサーバーは間違った時刻を提供する
  • ネットワークの問題 (高レイテンシによりこのようなドリフトが発生する可能性がありますか?)
  • うるう秒によって引き起こされるバグ (代わりにクラッシュを引き起こすはずですよね?)

最初の選択肢が問題だった場合、どうすればこれを防ぐことができますか?

serverNTPD は、複数の NTP サーバー (で複数の行が利用可能な場合ntp.conf) を参照して、異なる回答が互いに大きく異なるかどうかを検出できるほどスマートですか?

答え1

数年前、Slackware マシンでそのような syslog エントリを見たことがあります。問題のマシンを購入したのは 2002 年だったと思いますが、何年もの間、ほぼ 24 時間 365 日稼働していました。SSH、SMTP、HTTP サーバーでした。NTP 障害は徐々に発生し、頻度が徐々に増加しました。

最初は、マザーボード上のコインサイズ (米国の 25 セント硬貨) の CR2032 バッテリーの 1 つである「CMOS RAM」バッテリーを交換することでこの問題を解決しました。

1、2 年運用した後、そのマシンは時間を正確に維持できなくなり、定期的に再起動する必要がありましたntpd。私の理解では、 は、ntpdローカル クロックとネットワーク クロックの差に関する過去のデータに基づいて「スキュー ファイル」を保持しています。私の推測では、問題のマザーボードのクロックはそれほど優れておらず、クロックが最終的に悪くなり、「スキュー ファイル」がその大きな変動に対応できなくなったのだと思います。

関連情報