NTP分散とは何ですか？

顧客が提供する複数のNTPサーバーを使用するように構成されたntpd 4.2.6p5を実行する、隔離されたネットワーク上のUbuntu 14.04サーバーを展開します（pool.ntp.orgへのアクセスなし）。ダム端末クライアントデバイスは、古いバージョンのBusyBox（1.00-rc2）とLarry Doolittleのntpclient 2010を実行します。

このセットアップは長年にわたってうまく機能していましたが、最近、新しい顧客に障害が発生しました。ntpdate-debianLinuxサーバーに関する限り、5つの社内NTPサーバーアドレスを提供してくれました。ただし、BusyBox側では、ntpclient「分散が高すぎる」と文句を言います。デバッグ出力ntpclientから、NTPサーバーから「1217163.1」を取得しますが、サポートする最大値はabsolute（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

これらはすべて同じLAN上にあるデバイスなので、率直に言って驚labします。驚きました。

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

私の質問は：

1. 分散とは何ですか、またその価値を変えることができるものは何ですか？
2. NTPサーバーから詳細を取得するために実行できるコマンドは何ですか？
3. 障害は、Ubuntuサーバー側にありますが、不適切ntp.confですか？本当に特別なものはありません。
4. この場合、chronyに切り替えると何か変更されますか？

ここでの回答には混乱が見られます。まずntpclient、少なくとも-sモードでは、完全なNTPクライアントとして機能せず、1パケットのみを送受信するため、「最後の8パケットを受信しません」。実際には、独自の分散を推定しているわけではありません。

代わりに、印刷する値は、サーバーによって返されるパケットの「ルート分散」（rootdisp）と呼ばれる値であり、これはそのサーバーと正しい時間の間のエラー/分散の合計量の推定値です。これを計算する方法は非常に簡単です。すべてのNTPサーバーは、外部クロック（ラジオやGPS受信機など）または別のNTPサーバーから時刻を取得します。サーバーが外部クロックから時刻を取得する場合、そのルート分散はそのクロックの推定最大誤差です。別のNTPサーバーから時刻を取得する場合、そのルート分散は、そのサーバーのルート分散と、それらの間のネットワークリンクによって追加された分散です。

ここでの混乱の1つのポイントは、ntpqとchronyが分散とルート分散を秒単位で表示するのに対し、ntpclientはそれをマイクロ秒単位で表示することです。とにかく、1217163の値はまだ非常に高いです。優れたNTPサーバーは、数ミリ秒以内に時間を把握しています。数十または数百ミリ秒以内に悪いもの。あなたのものは、その時間は+/- 1.2秒以内にしか信頼できないと言っています。

あなたが実際に渡すことで、とにかくこのサーバに同期させるNtpClientで取得することができます-x 0または-tNTPの健全性チェックを無効にするオプション（NtpClientでのバージョンに応じて）、。大まかに正確な時間（数秒以内）のみが必要な場合は、それで十分です。ただし、ntpclientは、このような不良サーバーとの同期を拒否するのにかなり合理的です。あなたのntpqUbuntuマシン上の出力は、彼らは非常に信頼性の低いネットワーク、陰謀のいずれかを示し、低遅延、持っているにもかかわらず、そのサーバのすべてのために数百ミリ秒のジッタを示しているすべての不規則な時間を提供するためのサーバ、または基本的にサーバー自体の時間管理の問題。

また、サーバー10.31.10.22がrefid LOCL（非規律のローカルクロック）をアドバタイズしているが、ストラタムが1であることに懸念があります。群れがばらばらにならないようにします。10.31.10.22が誤って設定されており、ネットワークの残りの部分に悪い時間を提供している、またはNTPの制御外のプログラムによって良い時間に統制されています。その場合、設定の誤りは単にLOCLrefidをアドバタイズすることです。たとえばGPS、その時間を提供しているものに上書きする必要があります。

「分散とは」に対する部分的な答え：

典型的なNTPラウンドトリップ：

client |        | server
    t1 |------->| t2
    t3 |<-------| t4

これにより、次の式を使用して、オフセット（クライアントとサーバー間の時間差）、および遅延（本質的なネットワーク移動時間）の2つの値が得られます。

offset= ((t4 - t3) + (t1 - t2)) / 2
delay = (t4 - t1) - (t3 - t2)

クライアントは、最後に受信した8つのパケットから現在のオフセットを選択し、遅延が最小のパケットを選択します。

同じ8パケットを使用して、これらの8つのオフセットと最後のステップで選択したオフセットとの差の加重平均を行い、分散を計算します。これは、値の「広がり」の尺度であり、特に複数の選択肢がある場合は、タイムサーバーの品質を計算するために使用されます。

分散とスキューは非常に大きく、ローカルクロックからそのピアまでのオフセットが非常に大きくなります。オフセットをローカルdateと比較し、手動でクロックを設定する必要があります。

ntpdを実行し、ntpq -pすべてのピアを使用してホストから表示します。より良いものを選択します。

このシスコのドキュメントによると、「秒単位で報告される分散は、ローカルクロックとサーバークロック間でこれまでに観察された最大クロック時間差です」。完全に壊れていないntpサーバーでは、高分散は決して発生しません。唯一の実行可能なシナリオは、クライアントがntpを初期化し、これまでローカルクロックのみを使用できる場合です。そして、それでも、あなたが報告するほどのばらつきは、2週間以上ずれているクロックに対応します。

BIOSでクロックを調整し（および日付さえも！）、ntpdate開始前に1回発行することにより、ローカルクロックが最初にあまり遠くないことを保証するのに十分である必要があります（数時間でも許容されます）。ntpdクライアントで。