解決策 1:
ここでの回答には混乱が見られます。まず、ntpclient 、少なくとも -s で モードでは、完全な NTP クライアントとして機能していません。1 つのパケットのみを送受信しています。 、したがって、「最後に受信した 8 パケット」はありません。実際には、それ自体の分散をまったく推定していません。
代わりに、それが出力している値は、サーバーから返されたパケットの「ルート分散」(rootdisp) と呼ばれる値です。これは、そのサーバーと正しい時刻との間のエラー/分散の合計量の推定値です。これを計算する方法は非常に単純です。すべての NTP サーバーは、外部クロック (ラジオや GPS 受信機など) から時刻を取得するか、別の NTP サーバーから時刻を取得します。サーバーが外部クロックから時間を取得する場合、ルート分散はそのクロックの推定最大誤差です。別の NTP サーバーから時刻を取得する場合、そのルート分散はそのサーバーのルート分散 plus になります。 それらの間のネットワーク リンクによって追加された分散。
ここで混乱する点の 1 つは、ntpq と chrony が分散とルート分散を秒単位で表示するのに対し、ntpclient はそれを マイクロ秒 で表示することです。 .とにかく、1217163 という値は依然としてかなり高い値です。優れた NTP サーバーは、数ミリ秒以内に時刻を認識します。数十または数百ミリ秒以内に悪いもの。あなたの時間は +/- 1.2 秒以内にしか信頼できないと言っています。
-x 0 を渡すことで、ntpclient をこのサーバーに同期させることができます。 または -t オプション (ntpclient のバージョンに依存)。NTP のサニティ チェックを無効にします。おおよその正確な時間 (数秒以内) だけが必要な場合は、それで十分かもしれません。ただし、ntpclient がそのような悪いサーバーとの同期を拒否するのは、かなり理にかなっています。あなたの ntpq ubuntu マシンの出力は、サーバーの遅延が少ないにもかかわらず、すべてのサーバーで数百ミリ秒のジッターを示しています。これは、ネットワークの信頼性が非常に低いか、すべての サーバーの不規則な時刻、またはサーバー自体の基本的な時間管理の問題。
また、サーバー 10.31.10.22 が LOCL の refid をアドバタイズしていることも気になります。 (統制されていないローカル クロック) ですが、ストラタムは 1 です。通常、ローカル クロックは 10 のストラタムにファッジされるため、群れがバラバラにならないようにするための最後の手段の同期ソースとしてのみ使用されます。 10.31.10.22 の構成が誤っていて、ネットワークの残りの部分に悪い時間を提供しているか、NTP の制御外にあるプログラムによって適切な時間を制御されているかのいずれかです。この場合、構成の誤りは単に LOCL 再調整;オーバーライドする必要があります。 GPS またはその時間を提供しているものは何でも。
解決策 2:
「分散とは何ですか?」に対する部分的な回答:
典型的な NTP ラウンドトリップ:
client | | server
t1 |------->| t2
t3 |<-------| t4
これにより、オフセット (クライアントとサーバー間の時間差) と遅延 (ネットワーク移動時間に不可欠) の 2 つの値が次の式で得られます:
offset= ((t4 - t3) + (t1 - t2)) / 2
delay = (t4 - t1) - (t3 - t2)
クライアントは、受信した最後の 8 つのパケットから現在のオフセットを選択し、遅延が最小のものを選択します。
分散の計算には、同じ 8 つのパケットが使用されます。 これらの 8 つのオフセットと最後のステップで選択されたオフセットとの差の加重平均を行うことにより、遅延が重み係数として使用され、小さい遅延に大きな重みが与えられます。これは、値の「広がり」の尺度であり、特に複数の選択肢がある場合に、タイム サーバーの品質を計算するために使用されます。
解決策 3:
分散とスキューは非常に大きく、ローカル クロックからそのピアまでのオフセットが非常に大きくなっています。オフセットをローカルの date と比較する必要があります 時計を手動で設定します。
ntpd を実行して ntpq -p を表示します すべてのピアを使用するホストから。より良いものを選択します。
解決策 4:
このシスコのドキュメントによると、「分散 、秒単位で報告され、ローカルクロックとサーバークロックの間でこれまでに観察された最大クロック時間差です」.完全に壊れていないntpサーバーでは、大きな分散は決して発生しないはずです.唯一の実現可能なシナリオは、クライアントがntpを初期化する場合ですこれまでのところ、ローカル クロックしか利用できません。それでも、報告されたような高い分散は、2 週間以上ずれているクロックに相当します。 .
BIOS でクロック (および日付も!) を調整するか、 ntpdate ntpd を開始する前に 1 回