Linuxマシンでシステム時刻を正確に設定するためにgpsdとntpdに依存するアプリケーションがあります。
gpsdにはNMEA+PPSが供給されます
アプリケーションはネットワーク上で毎秒最大25MBをパンニングしており、システムの負荷が何らかの形で時間のジッターを引き起こしていると思います。（ロードされたPCI Expressバスにより、不規則な割り込みレイテンシが発生します）
GPSを読み取り、ロードされたマシンのNTPサーバーとして機能するようにセットアップできる、まったくロードされていない別のマシンがあります。（ロードされたマシンはstartum 1を取得します???）
イーサネット上の同じサブネット上のストラタム0NTPサーバーからの時間はどれくらい正確であると期待できますか？
これがあまり話題から外れていないことを願っています。いつか他の誰かが答えをここに文書化して喜んでくれると確信しています。;-)
NTP の精度で見つけた最良の情報は、LAN 設定で 1 ～ 2 ミリ秒を指しているようです。
それをサポートするためのカーネル mod を備えた NTP v4 は、1ms よりもはるかに優れた精度、おそらく 1ns の精度が可能です。[Dave Mills] の記事によると、NTP v3 は LAN で 1 ～ 2 ミリ秒、WAN ネットで数 10 ミリ秒の精度です。http://www.cis.udel.edu/~mills/ntp.html
他の記事では、GPS タイム ソースなどの正確なタイム ソースを使用すると、NTP は 50us まで正確であることが示唆されていますが、Linux カーネル サポートのリンクでは、数ミリ秒の精度が可能であると記載されています。 http://www.atomic-clock.galleon.eu.com/support/ntp-time-server-accuracy.html
別の記事では、ネットワーク遅延の予測可能性 (つまり、低ジッタ ネットワーク) に依存していると述べています。 http://www.postel.org/pipermail/end2end-interest/2003-April/002925.html
NTP は通常、この種の状況で 1 桁の小さな ms に適していると見なされます。
ntpd は非常に長い時定数フィルタリングのヒープを実装しているため、数日間実行した後、実際のクロックのいずれにも大きなジッターはありません。
ただし、時間をどのように測定しているかについては実際には述べていません。使用しているメカニズムが何であれ、基礎となる同期と同じくらい（それ以上ではないにしても）ぎくしゃくしている可能性があります。
ネットワークがビジー状態で、バッファリングが非常に深いネットワーク カードがある場合、パケットの到着と割り込みサービスの間のジッターが大きくなるため、問題が解決しない可能性があります。イーサネット スイッチングが洗練されているほど、タイミングも悪化します。この点では、昔ながらのハブの方がスイッチよりも優れています。
問題のNTPサーバーの階層レベルは、クロック/サーバーの精度とは関係ありません。それは純粋にあなたがいる「基準時計」からの距離を意味します。
さらに重要なのは、NTPの精度（もちろん時間に関して）に関して、サーバー間のネットワーク遅延、使用されているサーバーのタイプ、および潜在的にサーバーの負荷です。使用するNTPサーバーに応じて、時刻がどれだけ正確になるかを文書化します。各サーバーソフトウェアは、さまざまなアルゴリズムを使用して、ネットワーク遅延とサーバー負荷に基づいて時間を計算します。これは、それらのアルゴリズムの精度に帰着します。
たとえば、MS NTPサーバーは、2秒以内に正確になると述べています。OpenNTPdは、サーバーの可能な精度を提供しないと述べています。ストラタム3サーバーがストラタム2サーバーよりも正確である場合などがあります。