分離ネットワーク上の単一のNTPサーバー

隔離されたネットワーク上に2つのLinuxマシン（AとB）があります。それらは時間同期されている必要があります。マシンAは断続的に電力が供給され、信頼できるタイムソース（GPS）に接続されているため、時間を提供する必要があります。マシンBは、マシンAに電力が供給されている場合にのみ電力供給されますが、組み込みLinuxデバイスであり、その電力状態は頻繁に変化します。どちらのマシンも他のシステムにアクセスできません。それは閉じたネットワークです。

NTPは通常、複数のサーバーとの通信を想定しているため、これはNTPにとって非常に難しい注文であることを理解しています。これをマシンBで正常に機能させるのに問題があります。マシンAはGPSと正常に同期し、マシンBはマシンAに到達でき、時間クエリも実行できますが、マシンAは信頼されていません（おそらくそれ自体ですか？）。マシンAが安定して1時間稼働した後、これは突然変化し、マシンBが動作しました。ただし、マシンA（およびマシンB）がダウンすると、マシンBは再び適切な時間同期を見つけることができなくなります。

これがntpdateの情報です。マシンAのストラタムが1の場合でも、最後に同じ出力で操作が失敗することに注意してください。

10.10.10.1：サーバーが削除されました：階層が高すぎます
サーバー10.10.10.1、ポート123
階層16、精度-19、飛躍11、信頼000
refid [10.10.10.1]、遅延0.02614、分散0.00000
送信4、フィルター4
参照時間：00000000.00000000 Thu、Feb 7 2036 6：28：16.000
元のタイムスタンプ：d3a9bdc4.27ebb350 2012年7月12日木曜日21：19：00.155
送信タイムスタンプ：bc17c803.b42dfffe Sat、Jan 1 2000 0：25：39.703
フィルター遅延：0.02625 0.02614 0.02618 0.02625 
         0.00000 0.00000 0.00000 0.00000 
フィルターオフセット：39544160 39544160 39544160 39544160
         0.000000 0.000000 0.000000 0.000000
遅延0.02614、分散0.00000
オフセット395441600.451568

 1月1日00:25:39 ntpdate [677]：同期に適したサーバーが見つかりません

私の推測では、マシンAは時間を提供すること自体を信頼していません。51分の稼働時間（以前に起こった可能性がありますが、私にはわかりません）とそのクロックがGPSに同期された後、マシンAが時間を正しく提供し始め、マシンBがそれを取得しました。私はこれがもっと早く起こるために必要です。可能であれば、数秒以内に。

次の構成（および多くの待機）を使用すると、最終的には成功します。

マシンA ntp.conf：

サーバー127.127.28.0はtrue minpoll 4 maxpoll 4を優先します
ファッジ127.127.28.0ストラタム1時間1 0.420 refid GPS 

マシンB ntp.conf：

サーバー10.10.10.1はtrue minpoll 4 maxpoll 4を優先します

マシンBでntpq -cピアが適切な時間の修正なしでピアリングします。

     ポーリングが遅延オフセットジッタに到達したときのリモートrefid st t
================================================== ============================
 10.10.10.1 .STEP。16 u 9 16 0 0.000 0.000 0.000

マシンBのntp1 -cピアが適切な時間に修正されました。

     ポーリングが遅延オフセットジッタに到達したときのリモートrefid st t
================================================== ============================
* 10.10.10.1 SHM（0）2 u 7 16 17 0.669 2.597 1.808

それで、今問題は次のようになります：どうすればMachine Aをすぐに自分自身に信頼させるのですか？

マシンBの前後のマシンAからの一部のデバッグ出力は、マシンAが使用するのに十分であると判断します。

前..

〜＃ntpq -c rv
associd = 0 status = c418 leap_alarm、sync_uhf_radio、1イベント、no_sys_peer、
version = "ntpd 4.2.6p4@1.2324 Fri Feb 24 15:01:45 UTC 2012（1）"、
processor = "armv7l"、system = "Linux / 2.6.35.14"、leap = 11、stratum = 2、
精度= -19、rootdelay = 0.000、rootdisp = 44.537、refid = SHM（0）、
reftime = d3ab0053.43b44780金、2012年7月13日20：15：15.264、
clock = d3ab0062.e7e03154金、2012年7月13日20：15：30.905、peer = 34819、tc = 4、
mintc = 3、offset = 0.000、frequency = 0.000、sys_jitter = 3.853、
clk_jitter = 36.492、clk_wander = 0.000

あと...

〜＃ntpq -c rv
associd = 0 status = 0415 leap_none、sync_uhf_radio、1イベント、clock_sync、
version = "ntpd 4.2.6p4@1.2324 Fri Feb 24 15:01:45 UTC 2012（1）"、
processor = "armv7l"、system = "Linux / 2.6.35.14"、leap = 00、stratum = 2、
精度= -19、rootdelay = 0.000、rootdisp = 41.278、refid = SHM（0）、
reftime = d3ab0063.43b37856 2012年7月13日金曜日20：15：31.264、
clock = d3ab006d.9ee53ec2 Fri、Jul 13 2012 20：15：41.620、peer = 34819、tc = 4、
mintc = 3、offset = 0.000、frequency = 43.896、sys_jitter = 0.762、
clk_jitter = 36.953、clk_wander = 0.000

NTPは正常に動作するはずです。起動時の高速同期のオプションのいくつかを見てください。見てくださいburstとiburstのシステムB.ルックのためのオプションtrueのGPSクロックソースのオプション。

両方のシステムでバックアップタイムソースとしてハードウェアクロックを使用することを検討してください。より高い階層システムBを設定します。次のようなものが機能します。

server  127.127.1.0
fudge   127.127.1.0 stratum 8

の出力ntpq -c peersを見て、信頼できるクロックソースを取得するタイミングを確認してください。通常ntpは、信頼する前に、信頼できるタイムソースからの多数の応答が必要です。これは、各行の最初の文字で示されます。

NTPはより多くのソースを好みますが、1つの階層レベル内の奇数のタイムソースはうまく機能します。サーバーとGPSクロックが2つしかないため、ソースの優先度（層）は、GPS、サーバーAのクロック、サーバーBのクロックから増加する必要があります。各層の間の層を3レベルまたは4レベル増やすと、優先順位が確実に守られます。

編集：サーバーAにbusybox NTPサーバーがある場合、完全なntpサーバーパッケージをインストールする価値があります。サーバーAで何が起こっているのかを理解することは、問題を解決するのに大いに役立つはずです。サーバーBが信頼する前に、少なくとも1つの信頼できるタイムソースが必要です。ntpq -c peers動作しない場合は、を試すことができますntpdc peers。これらのコマンドの両方を使用して、他のホストを照会できます。peerstatsログも有用である可能性があります。

サーバーBでは、busybox ntp howtoに記載されているntpclientを使用して、何が起こっているかをログに記録します。

サーバーが長時間ダウンしていない場合、クロックは正しい時刻にかなり近いはずです。2つのシステムを同期する必要がある場合は、それで十分です。GPSは、時間を実際の世界と同期させます。

'ntpd -q'は迅速に同期しますが、終了します（ntpdate動作）。ntpd継続的に同期するには、終了オプションなしのコマンドを続ける必要があります。

EDIT2：サーバーをチェックしたところ、サーバーの1つが1秒ずれていることがわかりました。これを修正しながら、設定で遊んだ。iburstサーバーを非常に迅速に信頼します。 true他に信頼できるソースが複数ない場合は、クロックドライバーが信頼できることを確認しました。時計は、ローカルで信頼され、リモートで信頼できるようになるまでに1分強かかりました。

テストするときntpdは、同期が完了したらプロセスを再起動し、設定がどのように高速に機能するかをテストできます。上記の場合、同期の速さをテストするためにサーバーBを再起動する必要があります。ntpd変更を監視するとき、次のような行を使用します。

while ntpq -c peers localhost; do sleep 10; done

ホスト名とスリープ時間は必要に応じて調整されます。場合によってntpqは、ループ内で2つ以上のコマンドラインをチェーンします。その際、echoコマンドやdateコマンド、あるいはその両方を使用して、データセットがどこで変化するかを示します。