2017-07-04 16 views
0

NMEA GPSレシーバに基づいてNTPサーバを実装しようとしています。ルートディレイフィールドに何を書き込むのかわからない。プライマリNTPサーバ(GPSレシーバ)の実装

私はNTPv4 specificationを読んでおり、ルート遅延は基準クロックへの総往復遅延であると書かれています。

私がセカンダリサーバで作業している場合、参照サーバとのパケット要求を行うときのタイムスタンプの時間差からルート遅延を計算できます(正しいですか?)。

GPS受信機を基準クロックとして使用している場合は、何を記入するのかよく分かりませんが、代わりに0を入力してください。

答えて

0

これは、サーバーからGPSを受信するまでの時間によって大きく異なります。あなたがNMEA文を読んでそれを解釈して時計を設定しているなら、ルート遅延はそれを行うのにかかる時間でしょう。しかし、それは非常に良い時計ではありません。 RS232の読み込みには、(GPSに接続していると仮定して)多くの非決定的な遅延(ジッタ)があります。

GPS受信機の1パルス/秒出力を使用して修正できます。これは通常、データキャリア検出ピンにあります。適切なRS232ポート(USBではない)を使用すると、サーバのクロックを同期させることができます(DCDを使用して割り込みを発生させることができます)。これは確かにSolaris(カーネルのネイティブ部分)やLinuxでも(http://support.ntp.org/bin/view/Support/ConfiguringNMEARefclocks)行うことができます。あなたがこれをしているなら、私はルートの遅延は小さいと思うが、OSとハードウェアの応答時間の問題がある。 this NTP docs pageによれば

EDIT

ルート遅延

これは におけるプライマリ基準ソースに合計往復遅延秒同期サブネットのルートです。この 変数は、 クロックの精度とスキューに応じて、正と負の両方の値をとることができます。

したがって、1PPSではかなり低くなります。これまでのところ、セカンダリNTPサーバがクライアントに参照クロックに対する遅延を伝えるために使用するフィールドであることはわかります。したがって、1PPSのロックされたGPSタイムソースがある場合は、リファレンスクロックです。どちらの場合でも、おそらくゼロは十分です。私は、NTPがコンピュータのIRQ応答時間より良いネットワーク間時間同期精度(最高で1ms)を達成できるとは思わない(うまくいけば、CONFIG_PREEMPT_RT Linuxカーネルがうまくいけば何も起こらないだろう)。

+0

はい、私はそれが非常に正確であることを読んだので、実際の秒を同期するためにPPS出力を使用しました。したがって、この場合、ルート遅延は、PPSパルスによって生成された割り込みに対するOSとハードウェアの応答時間になりますか?どのように私はそれを計算する必要がありますか?それとも無視できるほど小さいのですか? – zeluqa

+0

@zeluqa、編集済み – bazza

関連する問題