私はntpsec
不安定なDebianバージョンを使用しています。マイログには次のものが表示されます。
Mai 22 11:48:34 services ntpd[13428]: CLOCK: time stepped by 1.442261
Mai 22 11:55:06 services ntpd[13428]: CLOCK: time stepped by 1.524066
Mai 22 12:03:00 services ntpd[13428]: CLOCK: time stepped by 1.702944
Mai 22 12:08:34 services ntpd[13428]: CLOCK: time stepped by 1.517894
Mai 22 12:17:38 services ntpd[13428]: CLOCK: time stepped by 1.434055
Mai 22 12:24:07 services ntpd[13428]: CLOCK: time stepped by 1.084220
Mai 22 12:32:29 services ntpd[13428]: CLOCK: time stepped by 1.562280
Mai 22 12:38:38 services ntpd[13428]: CLOCK: time stepped by 1.211420
Mai 22 12:43:49 services ntpd[13428]: CLOCK: time stepped by 1.185642
Mai 22 12:48:58 services ntpd[13428]: CLOCK: time stepped by 0.796154
Mai 22 12:54:43 services ntpd[13428]: CLOCK: time stepped by 1.331323
Mai 22 13:00:21 services ntpd[13428]: CLOCK: time stepped by 0.849190
こんなことは今日だけではなく数日目続いています。明らかにntpd
、システムクロックドリフトが正しく修正されていません。常に以下があります/var/lib/ntpsec/ntp.drift
。
500.000000
私が今試したこと:
- カーネルが RTC を自動的に更新しないように CONFIG_RTC_SYSTOHC を無効にします。数時間後に
hwclock -w --update-drift
RTCを読み取ろうとすると、少なくとも精度が良くなりました。ドリフト係数を0.78秒/日に設定します。 - その後、私は
adjtimexconfig
システムクロックを修正するために走りました(それはntpd
もともとするべきことです)。それは言う:Comparing clocks (this will take 70 sec)...done. Adjusting system time by 275,531 sec/day to agree with CMOS clock...done.
ntpd
その結果、今は多くの時間を減らす必要があるようです。
Mai 22 14:24:20 services ntpd[13428]: CLOCK: time stepped by 0.234963
Mai 22 14:30:30 services ntpd[13428]: CLOCK: time stepped by 0.145163
さて、なぜntpd
自分でやってみるのはどうですか? 0.2秒/6分はまだあまりにも不正確だと思うので、このプロセスを何度も繰り返す必要があるようです。どんな提案がありますか?
答え1
何らかの理由でオペレーティングシステムの時計非常に不正確です。正確な時間は通常、ntpd
次のように維持されます。回ってつまり、遅い時計にリアルタイムに追いつくように「速度を上げる」ように指示し、実際にリアルタイムと同期している場合にのみ、時計の速度をリアルタイムに一致させるように調整し、同期しすぎると時計の速度を遅くします。高速。
しかし、オペレーティングシステムの時計の場合、この調整だけでは十分ではないようです。エラーが大きすぎるため、ntpd
ステップ調整が必要であり、本質的にシステムクロックを数分ごとに正しい時間にリセットする必要があります。データベースなどの正確なタイミングが必要な場合は、ステップ調整を完全に避ける必要があります。あなたはする必要がありますいいえゼロ以外のステップのサイズ変更に満足してください。
幸いなことに、誤差は常に同じ方向に現れるように見え、調整が可能な系統的な誤差である可能性が高いです。
メモ:これが仮想マシンの場合、高負荷で実行されている仮想化ホストと使用量の多いVMを実行するためにアイドル状態のVMから「時間を盗む」時間ドリフトが発生する可能性があります。この場合は、まず仮想化ホスト管理者に推奨されるタイミングを変更する方法についてお問い合わせください。仮想マシンが本質的にタイミングのためにホストクロックを使用できるようにする「半仮想化クロック」オプション、またはホストソリューションOSが推奨する他のオプションがあります。 /ハイパーバイザーサプライヤー。 NTP 同期を使用する場合は、仮想化ホストが仮想マシンの時計を妨げないようにしてください。 2つのうちの1つだけではなく、2つのうちの1つだけを邪魔してください!
hwclock -w --update-drift
バッテリサポートRTCクロックのドリフトは、バッテリサポートRTCクロックをオペレーティングシステムクロックと比較して推定されます。したがって、既知の不良時計と一致するように潜在的に良い時計を調整することになりますが、これは良い考えではないようです。
adjtimexconfig
一方、バッテリ駆動のRTCが正しいと仮定し、それに合わせてオペレーティングシステムの時計のパラメータを調整します。既知の良いNTPタイムソースにアクセスできる場合は、オペレーティングシステムのadjtimex --host <NTP server>
時計をNTPサーバーと直接比較してから(ntpd
この操作の実行中に停止)、adjtimex -p
結果frequency
とtick
値を確認するために使用する必要があります。
または、設定されたオフセット値をadjtimex -p
確認するために使用することもできます。値のみが調整され、設定にはまったく影響しません。frequency
ntpd
ntpd
frequency
tick
周波数オフセット値が+/- 32768000の範囲の終わりに達した場合は、tick
手動で値を調整してプロセスを繰り返す必要があります。
(frequency
最大正の値に達したり近づいたりすると、ツールが時計の速度を上げようとしますが、調整範囲外であるため十分に速く速度を上げることができません。この問題を解決するには、値を上げてくださいtick
。frequency
する場合、tick
値を減らします。)
tick
周波数オフセット値を相対的に中間範囲値(約+/- 5000000など)に近づけて保持する値を見つけると、ntpd
必要に応じて周波数オフセット値を調整してクロックを同期状態に保つ可能性が高くなります。スケール値を手動で編集し、/etc/default/adjtimexconfig
起動adjtimex.service
時に正常な実行を保証する必要があります。起動前に実行されるため、ntpd
OSクロックは「クルーズコントロール」の役割を開始する前に「正しいギア」に設定されます。ntpd
OSクロックを制御するとntpd
同期状態が維持され(最初の列にアスタリスクが表示されますntpq -np
)、ブート時に1回を除いてステップ調整に関するログメッセージがなく、hwclock -w --update-drift
RTCのドリフト速度を使用して推定できます。時計。最終結果は、電源が入っていてもオフになっていても、合理的な時間の間持続するシステムでなければなりません。
答え2
ああ…adjtimexconfig
それは答えではないでしょうか? !理由が何であれ、上記の操作のために書き込みntpd
更新が行われました/var/lib/ntpsec/ntp.drift
。過去60分間に2つのメッセージのみが受信されました。
Mai 22 15:59:45 services ntpd[13428]: CLOCK: time stepped by 0.241656
Mai 22 16:31:47 services ntpd[13428]: CLOCK: time stepped by 0.532398
今はかなり満足しているようです。
編集:telcoMのおかげで、すべての答えと解決策が得られたようです。まず、何が起こっているのかを説明します。 10000は明らかに初期値ですtick
。私のシステムでは遅すぎます。だからntpd
時間に合わせてずっと踏まなければなりません。ntp
調整はせずtick
細かい調整しかしないので、距離が遠すぎるとfrequency
力が制限され、何もできません。tick
それを使用したときにadjtimexconfig
問題は解決しましたが、tick
RTCによると正確ではありませんでした。 10031に設定されていますがtick
、これはまだ低すぎるため、ntpd
時間を超えて進む必要があります。これが500.000000 /var/lib/ntpsec/ntp.drift
(ntpd
更新されないようです)にとどまる理由です。これは頻度32768000(ドリフト* 65536)と同じです。
これでadjtimex -t 10038
問題が解決したため、突然tick
メッセージを表示できなくなりますCLOCK: time stepped
。ntpd
現在作業中なのでfrequency: -10025033
10037も使えると思いました。