オンラインでは時計を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のドリフトについて非常に興味深い議論があります

あなたの状況は異常であり、誰かが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を参照してください。

NTPにはすでにオンラインかオフラインかを知るメカニズムがあり、必要に応じて優先度の低いソースに切り替えます。リーチ値を確認して代替ソースをトリガーすることは非常に簡単ですが、NTPに固執します。以下で説明するように、RTCドリフトの監視と修正は難しい可能性があります。

インターネット以前には、データソースに電話をかけ、時計を同期させるプログラムを使用していました。モデムを介して時間ソースを提供するサービスがまだ利用できる場合があります。これには、電話回線へのアクセスが必要です。

ローカルクロックには、RTCには適用されない既知の問題があります。問題のいくつかは、NTP Known OS Issuesのリストに記載されています。これらはあなたのクロックドリフトを説明するかもしれません。それらを解決することで問題が解決する場合があります。ティックの欠落がない場合、ローカル（システム）タイムソースは非常に安定している可能性があります。

適切なRTC時間を/ dev / dumbclockXデバイスに書き込むプログラムで、ダムクロックドライバー（33）を使用できる場合があります。

ラジオクロックに基づいた他のドライバーがいくつかあります。これらの一部は、WWVやCHUなどの短波サービスを使用します。これらは、GPS信号が利用できない環境で機能する場合があります。ヨーロッパの場合、このリストにはBBC、TDF、RBU、およびRMWが含まれます。

Pavel KrejciもRTCドライバーを作成しましたが、公式ドライバーには組み込まれていないようです。これは、PPSタイプの同期で機能する場合があります。

展開の前にRTCドリフトを測定できる必要があります。ただし、RTCが自動的に更新されないようにする必要があります。システムクロックがadjtimex関数で更新されると、RTCは11分ごとに更新される場合があります。

NTPは、接続されるとクロックを更新します。通常、NTPはシステムクロックの大幅な調整を拒否します。クロックを調整できる範囲を調整するオプションがあります。

上記のRTCを使用するためのオプションを提案しました。電波時計は、GPS時計よりも適している場合があります。

信頼できる時間ソースがない場合にドリフトを比較して比較することは、おそらく無駄な努力です。現地時間が不安定な場合、RTCを監視するために現地時間を使用することはできません。カーネルが11分ごとにRTCを更新している場合、NTP接続中のドリフトの測定は機能しません。私が使用したRTCの解像度は1秒であるため、信頼性の高い測定を行うには大幅にドリフトしなければなりません。