web-dev-qa-db-ja.com

ntpdに小さなステップで変更を加えるように強制します

NTPドキュメントによると：

通常の条件下では、ntpdはクロックを小さなステップで調整して、タイムスケールが効果的に連続し、不連続性がないようにします- http://doc.ntp.org/4.1.0/ntpd.htm

しかし、これは私が実際に気づいたことではありません。システム時刻を手動で5秒または10秒前後に変更してから、ntpdを開始すると、時計が1回で調整されることに気付きます。

たとえば、次のコードを使用します。

#!/usr/bin/env python
import time
last = time.time()
while True:
    time.sleep(1)
    print time.time() - last
    last = time.time()

最初に時間を変更すると、次のようなことに気付くでしょう。

 1.00194311142 
 8.29711604118 
 1.0010509491

次に、NTPdを起動すると、次のように表示されます。

 1.00194311142 
-8.117301941 
 1.0010509491

ntpdに小さなステップで調整を強制する方法はありますか？

linuxntpd
5
David Wolever

合格ntpd -xデーモンを起動すると、変更が非常に小さく保たれます。クロックのステップはありません。もちろん、回転を設定することは、正しい時刻から非常に離れた場所から時計を開始した場合、大きなギャップを修正するのに時間がかかる可能性があることを意味します。いくつかの段落を引用する manページから

通常の条件下では、ntpdはクロックを小さなステップで調整して、タイムスケールが効果的に連続し、不連続性がないようにします。極端なネットワーク輻輳の条件下では、ラウンドトリップ遅延ジッターが3秒を超える可能性があり、ラウンドトリップ遅延の半分にエラーバジェット項を加えたものに等しい同期距離が非常に大きくなる可能性があります。 ntpdアルゴリズムは、128ミリ秒未満のサンプルオフセットがない間隔が900秒を超えない限り、128ミリ秒を超えるサンプルオフセットを破棄します。その後の最初のサンプルは、オフセットに関係なく、指定された時間にクロックをステップします。実際には、これにより、クロックが誤ってステップされた場合の誤警報率が、発生率がほとんどなくなります。

時計を10秒調整したので、NTPが期待していた領域を確実に超えて、ステッピングしました。

この動作の結果として、クロックが設定されると、ネットワークパスの輻輳やジッターの極端な場合でも、128ミリ秒を超えて外れることはめったにありません。場合によっては、特にntpdを最初に起動したときに、エラーが128ミリ秒を超えることがあります。これにより、ローカルクロック時間がサーバーに対して将来128秒を超える場合、クロックが逆方向に設定されることがあります。一部のアプリケーションでは、この動作は受け入れられない場合があります。 コマンドラインに-xオプションが含まれている場合、クロックはステップされず、スルー補正のみが使用されます。

-xオプションの使用を決定する前に、問題を注意深く調査する必要があります。 NTPプロトコルとアルゴリズムの設計の基礎となる正確性の原則の結果として、可能な最大スルーレートは500 ppmに制限されます。その結果、ローカルクロックが許容可能なオフセットに収束するまでに長い時間がかかる場合があり、1秒あたり約2,000秒が許容範囲外です。この間隔の間、ローカルクロックは他のネットワーククロックと一致せず、システムを分散に使用できません。正しく同期されたネットワーク時間を必要とするアプリケーション。

主要なサービスを開始する前にntpdateを実行してから、ntpd -xその後は、ステップレスの時間管理が必要になる前に主要なステップが確実に行われるようにするための優れた組み合わせソリューションになる可能性があります。

8
Jeff Ferland

これがあなたが書きたいコードのためのものであるならば、これはあなたが探している答えかもしれません： https://stackoverflow.com/questions/1205722/how-do-i-get-monotonic-time-durations -in-python

3
phillmv