オンラインでは時計をNTPと同期し、オフラインではRTCと同期しますか？
オンライン中にLinuxシステムをNTPと同期し、オフライン中に予想通りドリフトするRTCと同期する既存のメカニズムはありますか？ リモートの「コレクター」、つまりセンサーデータを収集してタイムスタンプを付ける組み込みLinuxシステムを運用しています。5秒未満など、適度に小さく保つには、クロックエラーが必要です。通常、NTPを使用してクロックを同期しますが、システムがオンラインである限り正常に機能します。 問題は、数時間、数日、さらには数週間ダウンする可能性がある非常に悪いアップリンクを持っているコレクターがあることです。これはローカルデータの収集を停止しませんが、NTPがないと、Linuxシステムのクロックはひどくドリフトし、予測不可能です。 OTOH、ハードウェアのRTCも大きくドリフトしますが、一定のレートです。RTCドリフト率はボードごとに異なりますが、ボードごとに一定であり、測定できます。 私たちに必要なのは、次のことを行うメカニズムだと思います。 実装前にボードのRTCドリフト率を測定します 可能な場合は、NTPを使用してシステム時間を継続的/定期的に調整します NTPが使用できない場合、RTCから定期的にシステム時間を調整します。既知のRTCドリフト率を考慮してください。 オプション：オンライン中に進行中のRTCドリフト率を測定および記録します（1） 「メカニズム」とは、「オンライン」と「オフライン」の2つの状態を処理できる、よく維持され、文書化されたソフトウェアおよび/または構成の一部を意味し、システムクロックが正しいタイムソース（ntp対rtc）、状態の変化を検出し、RTCドリフトを修正します。特別なntpd構成/プラグインとして、別個のデーモンとして、cronジョブとして、または他の方法で実装されているかどうかは重要ではありません。 Chronyを見てみましたが、そのドキュメントによると、システムクロックのドリフトを予測しようとします。この場合、RTCよりもはるかに予測しにくいドリフトが発生します。Chronyは、再起動後も時間を保つためだけにRTCを使用しているようです。 （1）注ntpdは、カーネルの「11分モード」をアクティブにします（11分ごとにシステムクロックからrtcを更新します）。現在のカーネルとntpdでは、11分間モードを防ぐ方法はないようです。したがって、ntpdの実行中にrtcドリフト情報は失われます（thx @billthor）。 更新/編集： USBまたはシリアル経由でMSFまたはDCF77信号（ヨーロッパに拠点を置く）に外部ラジオクロックを追加することを検討しています。しかし、むしろハードウェアを無駄のないものにしています。 私たちのコレクターは屋内、多くの場合地下にあります。したがって、GPSクロックを追加しても効果はありません。 Debian 7を使用します。これは、util-linux-2.20.1のhwclock、ntpdate-4.2.6p5、ntp-4.2.6.p5のntpd、chrony-1.24（潜在的には1.30）を意味します。 私たちの問題は、我々が使用する方法がわからないということはないことに注意してくださいntpdate(8)、hwclock(8)、date(1)、などで追加のセクションを参照してください斜体 i「はメカニズム」で何を意味するかについてを。 「11分間モード」に関する脚注を追加 ここでは、オフライン同期とRTCのドリフトについて非常に興味深い議論があります