web-dev-qa-db-ja.com

GPSクロックを使用したNTP時間同期の品質が悪いようです

GPSベースのNTPアプライアンスが近くにあります。サーバーからアプライアンスへのping時間は約1ミリ秒で、ジッターが非常に低いLinuxサーバーがあります。

 --- xxxxping統計--- 
 100パケット送信、100受信、0%パケット損失、時間99001ms 
 rtt min/avg/max/mdev = 0.874/0.957 /1.052/0.051ミリ秒

ただし、NTPクライアントは、時刻同期の精度を約5〜6ミリ秒と推定します。これは、セットアップを考えると非常に高いようです。

 NTPサーバー(x.x.x.x)の階層2 
時間内に同期 5ミリ秒
 16秒ごとにポーリングサーバー

ntpq -pは、次のようになります。

ポーリング到達遅延オフセットジッター時のリモートrefidstt 
 ============================== ================================================ 
 * xxxx .PPS。 1 u 10 16 377 0.964 -0.019 0.036 

2つの質問:

  1. NTPクライアントが同期の精度にそれほど低い信頼を持っている原因は何ですか?
  2. 同期の実際の精度を測定する方法はありますか?たとえば、ミリ秒単位で測定できますか?
7
NPE

ntpstatが「time correct to within」の後に表示する値は、ルート分散+ルート遅延/ 2です。ntpq -pは「ルート分散」の実行を表示しませんntpq -c rl代わりに。

それにもかかわらず、精度の欠如の主な原因は遅延ではなく分散(0.964のみ)であることは明らかです。

分散は、「一次参照ソースに対する公称誤差」です。私はNTPv4RFCを簡単に調べましたが、これは次のように言わなければなりません。

分散(イプシロン)は、測定に固有の最大誤差を表します。これは、最大の規律あるシステムクロック周波数許容値(PHI)に等しい速度で増加し、通常は15PPMです。 1 PPMは10 ^(-6)秒/秒に等しい。

Rrdtoolの用語を使用する場合、分散はゲージではなく、カウンターです。大きな値が表示されても、問題はありません。

残念ながら、この数を小さくする方法を理解するのに十分なntpアルゴリズムを理解できませんでした。この値が時々リセットされることに気づきました。理由はわかりません。

7
Mark Wagner

上記のハードウェアについて質問した理由は、多くのGPSデバイス(ストラタム0、「ルート」ソース)が、シリアルリンクを介してNTPサーバーとして機能する)コンピューターに接続するためです。

シリアル接続では、シグナリングオーバーヘッド/割り込み待機により、回線に1〜5ミリ秒のジッタが発生することがよくあります。したがって、私はあなたのNTP=ソースがシリアルソースから読み込んでいると思います。

シリアル接続でジッターを減らすために実行できる微調整がいくつかあります。 Primaily、FIFOを無効にすると、適切な結果が得られる場合があります。

http://support.ntp.org/bin/view/Support/KnownHardwareIssues#Section_9.1.5http://www.febo.com/time-freq/ntp/jitter/index.html

6
Chris Thorpe

5ミリ秒以内の正しい時間IS素晴らしい!!! 5ミリ秒は5/1000秒です。100ミリ秒未満のものは、ほんの一握りの状況以外では簡単に受け入れられます。 GPSを使用していませんが、ローカル原子時計と2つの外部基準時計を使用しています。ntpプールを使用すると、10ミリ秒以内に取得できます。

3
Liam