ntpd自体がドリフトを正しく更新できません。

何らかの理由でオペレーティングシステムの時計非常に不正確です。正確な時間は通常、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確認するために使用することもできます。値のみが調整され、設定にはまったく影響しません。frequencyntpdntpdfrequencytick

周波数オフセット値が+/- 32768000の範囲の終わりに達した場合は、tick手動で値を調整してプロセスを繰り返す必要があります。

（frequency最大正の値に達したり近づいたりすると、ツールが時計の速度を上げようとしますが、調整範囲外であるため十分に速く速度を上げることができません。この問題を解決するには、値を上げてくださいtick。frequencyする場合、tick値を減らします。）

tick周波数オフセット値を相対的に中間範囲値（約+/- 5000000など）に近づけて保持する値を見つけると、ntpd必要に応じて周波数オフセット値を調整してクロックを同期状態に保つ可能性が高くなります。スケール値を手動で編集し、/etc/default/adjtimexconfig起動adjtimex.service時に正常な実行を保証する必要があります。起動前に実行されるため、ntpdOSクロックは「クルーズコントロール」の役割を開始する前に「正しいギア」に設定されます。ntpd

OSクロックを制御するとntpd同期状態が維持され（最初の列にアスタリスクが表示されますntpq -np）、ブート時に1回を除いてステップ調整に関するログメッセージがなく、hwclock -w --update-driftRTCのドリフト速度を使用して推定できます。時計。最終結果は、電源が入っていてもオフになっていても、合理的な時間の間持続するシステムでなければなりません。