Windows がインターネット経由でシステム時刻を設定できるようにすると、次のダイアログが表示されます。
どのタイムサーバーを選択するかは重要ですか?
どれかが他のものより「優れている」かどうかはどうすればわかるのでしょうか?
答え1
どのタイムサーバーを選択するかは重要ですか?
短い答え: はい
すべての NTP サーバーは UTC との同期を維持するよう努めていますが、ユーザーからの距離や介在するネットワークが、遅延やジッターなどの NTP 要素に影響を及ぼします。また、可用性の問題もあり、すべてのサーバーが永久に継続的に利用できるわけではありません。
私の知る限り、UTC と Stratum-0 NTP サービスは、米国内であっても USNO によって監視、規制、提供されていません。UTC は ITU によって定義され、TAI とうるう秒 (ERS によって決定されたと思います) に基づいています。TAI は、70 の国際的な研究所 (USNO もその 1 つですが、ワシントンの NRL やボルダーの NIST も含まれます) によって維持管理され、フランスの BIPM によって調整されています。
私はntp プールあなたの地域の。
どれかが他のものより「優れている」かどうかはどうすればわかるのでしょうか?
適切なシステム上で実際のNTPクライアントを実行し、統計情報を確認することで
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
connorw600.info europium.canoni 16 u 182d 1024 0 0.000 0.000 4000.00
*dns0.rmplc.co.u ntp1.ja.net 2 u 659 1024 377 27.015 -4.936 1.034
+82.113.154.206 ntp4.ja.net 2 u 700 1024 377 24.853 -4.827 0.788
+dawn.rt.uk.eu.o ntp1.nl.uu.net 2 u 913 1024 377 29.364 -5.614 0.691
connorw600.info… は悪い選択のようです。
答え2
Wikipediaによると、ネットワークタイムプロトコル次のように動作します。
NTP クライアントは、リモート サーバーとクロックを同期するために、往復遅延時間とオフセットを計算する必要があります。往復遅延は として計算されます。ここで、は要求パケットの送信時間、は要求パケットの受信時間、 は応答パケットの送信時間、 は応答パケットの受信時間です。は、クライアント側で要求パケットの送信と応答パケットの受信の間に経過した時間で、 は サーバーが応答を送信する前に待機した時間です。オフセットは で与えられます。
クライアントとサーバー間の受信ルートと送信ルートの両方が対称的な公称遅延を持つ場合、NTP同期は正確です。ルートに共通の公称遅延がない場合、同期には、前方移動時間と後方移動時間の差の半分の系統的バイアスが発生します。
この説明から、正確なクロック同期を行うには、サーバーが要求に応答する遅延時間と、同期を完了するためにサーバーに応答する遅延時間の差を小さくする必要があることがわかります。したがって、実行しているサーバーが遠く離れている場合 (つまり、ユーザーと NTP サーバーの間に多くの「ポイント」またはルーターがある場合)、受信する NTP パケットと送信する NTP パケットの「パス」が異なる可能性が高くなります。
したがって、私の解釈では、時計を同期するのに最適なサーバーは「より近い」サーバーです。つまり、ユーザーとサーバー間の「ポイント」のトレースを取得した場合、ジャンプが少ないサーバーを選択することになります。Windows の「tracert」コマンドを使用して、最適なパブリック NTP サーバーを解決できます。
また、これらの標準オプション以外にも、多数のパブリックNTPサーバーインターネット上で。
答え3
短い答え: いいえ。
問題ではありません。すべて同じです。多かれ少なかれ、それらは互いのバックアップです。米国内では、米国海軍天文台のタイム サービス部門が公式のタイムキーパーです。企業、特に米国政府機関を含む他のすべての機関は、その時間を反映しています。したがって、ドロップダウンから選択できるオプションはすべて同じ時間です。したがって、他のオプションよりも「優れている」ものはありません。
答え4
実際には、レイテンシには大きな違いがあります。たとえば、プールを使用すると、さまざまなレイテンシが発生する可能性があります。プールは、ユーザーを近くのサーバーに接続しようとします。私の経験では、「検索」時間はクエリごとに異なります。あるアプリケーションでは、Google と Microsoft のレイテンシがより安定していたため、プールを第 3 レベルのバックアップにせざるを得ませんでした。