Linuxシステムをオンライン中にNTPと同期し、オフライン中にRTCを予測どおりにドリフトさせる既存のメカニズムはありますか?
私たちはリモートの「コレクター」を操作します。センサーデータを収集してタイムスタンプを記録する組み込みLinuxシステムです。 5秒未満など、クロックエラーをかなり小さく保つ必要があります。通常、NTPを使用してクロックを同期します。システムがオンラインである限り、これは正常に機能します。
問題は、一部のコレクターに非常に悪いアップリンクがあり、数時間、数日、または数週間もダウンする可能性があることです。ローカルデータの収集が停止することはありませんが、NTPがなければ、Linuxシステムクロックは大きく、非常に予測不可能にずれます。
OTOH、ハードウェアのRTCも大きく変動しますが、一定の速度で変動します。 RTCドリフトレートはボードごとに異なりますが、ボードごとに一定であり、測定することができます。
私たちが必要としているのは、以下を実行するメカニズムだと思います。
「メカニズム」とは、「オンライン」と「オフライン」の2つの状態を処理できる、よく管理され、文書化されたソフトウェアや構成の一部を意味します。システムクロックがタイムソース(ntp対rtc)を修正し、状態の変化を検出し、RTCドリフトを修正します。特別なntpd構成/プラグインとして実装されているかどうかは問題ではありません、別のデーモンとして、cronジョブとして、またはその他。
私は Chrony を調べましたが、その documentation によれば、システムクロックのドリフトを予測しようとします。私たちの場合、RTCよりもはるかに予測不能なドリフトが発生します。 ChronyはRTCを使用していて、再起動後も時間を維持しているようです。
(1)注意ntpdはカーネルの「11分モード」をアクティブにします(システムクロックからrtcを11分ごとに更新します)。現在のカーネルとntpdでは、11分のモードを防ぐ方法はないようです。したがって、rtpドリフト情報は、ntpdの実行中に失われます(thx @billthor)。
更新/編集:
ntpdate(8)
、hwclock(8)
、date(1)
などの使用方法がわからないことではないことに注意してください。italics「メカニズム」の意味について。あなたの状況は珍しいです、そしてあなたが望むことをするために誰かが標準のntpd
ベースの設定を思いついたら私は驚くでしょう。とは言っても、私は驚かれることを好みます、そしてそれはこれらの部分の周りでかなり頻繁に起こります。
しかし、誰かがより良いアイデアを思いつくまで、このようなcrontab
エントリを検討しましたか?
_*/5 * * * * ntpdate 0.pool.ntp.org || ( hwclock --adjust; hwclock --hctosys )
_
IEでは、5分ごとにntpdate
を介してクロックの同期を試み、失敗した場合(および失敗した場合のみ)、_/etc/adjtime
_ファイル(_man hwclock
_、およびその特定のRTCレートの知識を使用して適切に入力した最初の行)、次にRTCからシステムクロックを設定します。
このようなソリューションを採用し、これらのシステムのかなりの数を展開している場合、プールで作業し、使用量に比例してサーバーを提供することは礼儀正しいと見なされます。詳細については http://www.pool.ntp.org/en/vendors.html を参照してください。