クロックドリフトを測定および防止するにはどうすればよいですか？

いくつかの実稼働プラットフォームで、時刻が定期的に前後にジャンプしていることを示唆する症状が観察されています。ジャンプは通常約1秒で、通常はキャンセル（その後すぐにジャンプしてからジャンプ）し、1日に約50回発生します。このドリフトは、アプリケーションの使用率がピークのとき、および毎日のバックアップなどのディスクI / O操作が多いときに最も顕著になります。これらのドリフトは、リアルタイムのソフトに敏感なアプリケーションに影響を与えています。

システムは、3.0.58-0.6.6-defaultカーネルでSLES 11SP2を実行しているOracle Netra X4250およびNetra X4270サーバーです。

$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm

$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

NTPを無効にしましたが、ドリフトには影響しませんでした。時刻のずれを測定するツールはありますか？どうすればこれを回避できますか？

これらは実稼働プラットフォームであり、ラボで問題を再現することはできないため、実験する能力は限られています。自分のデバイスに任せたら、ドリフトを測定するツールを作成し、おそらくHPETクロックソースで実験します。

時刻のずれを測定するツールはありますか？

私が知っている唯一のツールは、十分なNTPツールです。特定のクロックソースと同期するようにntpdを実際に構成する必要はありません。計算されたオフセットを取得する-dオプションを使用ntpdateするだけです。

例：

[davisja5@xxxadmvlm08 ~]$ ntpdate -d clock.redhat.com 2>/dev/null | egrep "^offset"
offset -0.004545
[davisja5@xxxadmvlm08 ~]$

-d システムクロックに実際に触れることなくNTPを機能させるデバッグオプションです。

これを回避する方法に関するアドバイスはありますか？

ハードウェアクロックが原因である可能性があるため、開発環境やテスト環境でこれを再現できないことはそれほど驚くことではありません。誰かとのハードウェアサポートがある場合、私はあなたのマシンにサービスを提供しようとします。1つの可能性は、この生産マシンの開発マシンの1つを交換し、以前のPRODシステムを修正し、現在PRODにあるものを置き換えるための開発マシンとして再導入することです。

それ以外では、ハードウェアクロックソースを切り替えるだけで実行できます。あなたがスワップのことをしないかできない場合は、hpetルートに行くことをお勧めします。クロックソースがシステムサービスで混乱するかどうかをテストしてから、それを本番運用環境に展開します。

1つの解決策は、 HPET

高精度イベントタイマーもご覧ください。

ブートパラメータとして設定するには

clocksource=hpet

古いハードウェアでTSCは、多くの場合不安定で、カーネルによって無効にされていました。

マルチコア/ハイパースレッドCPU、複数のCPUを搭載したシステム、および休止状態のオペレーティングシステムの出現により、TSCを使用して正確な結果を提供することはできません...

ウィキペディア：タイムスタンプカウンター

クロック測定値と、アプリケーションが示すレイテンシーの症状を関連付けるためのより詳細なツールを作成しました。このツールは、Linuxの時刻クロックのジッターとして以前に疑っていたものを除外しているようです。

要するに、私の最初の仮説は無効でした。しかし、回答とリンクからLinuxクロックについて多くのことを学びました。

誰かが変更しない限り、時計は単調であると想定されていませんか？後方へのジャンプはできません。クロックを設定する何か-cronジョブまたは他のデーモン（たとえば、への呼び出しhwclock --adjust）が必要です。私は、ntp自体がドリフトの統計を更新し、定期的にそれを補正することを思い出します。長期間ntpを実行できず、大きなオフセットを取得できない場合、リセットしないと、その後数日間時間を台無しにします/etc/adjtime。そのような設定があります-時間ドリフトを定期的に再調整する（そしてジャンプを引き起こす）ものです。

ntp この問題に対抗するためのものです。