リアルタイムシステムにはリアルタイムクロック（RTC）が必要ですか？[閉まっている]

リアルタイムLinuxシステムと高解像度タイマーで構成されるハードウェアで作業していると仮定すると、RTCを持つことはシステムのリアルタイム性に影響しますか？

ここでは、CPUとメモリの使用量を削減すると述べていますが、どういうわけか違いを比較する方法はありますか？

リンクした記事は完全であり、まったくナンセンスです。「リアルタイムクロック」の「リアルタイム」（この記事で説明されているハードウェアデバイスの種類を指すために使用される）と「リアルタイムシステム」の「リアルタイム」はまったく異なる用語です。前者は、現在のカレンダー時間を保存し（通常、リンクされた記事のように高精度ではなく、非常に貧弱な近似）、長寿命のボタン/コイン型バッテリーを使用して、外部電源なしでそれを進めることを意味します。後者は、イベントの時間から応答の時間までの待ち時間のハードバウンドでイベントに応答することを意味します。

信頼できないと見なされるべきであることを確立するための、記事からの他のいくつかのビット

ほとんど無視できます。100年で1秒程度

100年に1秒は約317 pptです（はい、これは1 兆分の1です）。既存の市販のクロックテクノロジーでは、このようなクロックの安定性は得られません。1年に1秒に到達したとしても、少なくともOCXOが必要になります。これには、温度を調整する高出力で常時オンのオーブンが必要です。長寿命のコイン電池を搭載したデバイスでそれを手に入れることができるというアイデアは笑えます。

デジタル時計、出席システム、デジタルカメラなどのリアルタイムシステム

これらはどれもリアルタイムシステムと呼ばれるものではありません。

リアルタイムシステムは、指定された時間内に内部または外部のイベント/刺激に応答するものであり、その時間は通常ミリ秒またはマイクロ秒です。RTCではなく、精度の低いタイマーが必要です。

そして、あなたの質問に対する答えは「いいえ」です。システムのリアルタイム性には影響しません。

リセット後にRTCを使用してシステムがオフラインになっている場合、適切な日付をログに記録できます。ログを調べる必要がある場合、ログは巨大になる可能性があり、タイムスタンプを間違えると、ソフトウェア開発者とクライアントが夢中になり、一般的な調査ではほとんど不可能になります。

あなたが言及する記事で簡単か難しいか、低いか高いかは一種の個人的な意見です。以前にそれをやったことがなく、明確なシステム要件と作業指示書がないと、困難で費用がかかります。必要なものと使用するのに最適なデバイスがわかっていれば、簡単で安価です。

これは、「リアルタイム」という用語の使用に関する用語の問題のようです。

リアルタイムクロック

リアルタイムクロックは、安定/正確な（ある程度の許容範囲内で）計時のためのデバイスであるため、ホストシステムはそれを使用してイベント/アクションを発生日時に関連付けることができます。

リアルタイムクロックは、コンピューターに接続されたデジタル時計の内部に似ていると考えることができます。安定しており、かなり正確になるように設計された、独立して電力供給される時間基準があります。デジタル時計のように、ホストコンピューターがシャットダウンされたからといって、現在の時刻が失われることはありません。ユーザーがシステムを起動するたびに現在の時刻と日付を再入力したり、ドリフトを補正するために頻繁に調整する必要がないように、リアルタイムクロックは主に利便性としてコンピューターに取り付けられています。

リアルタイムクロックの代替手段は、システムクロックで駆動されるソフトウェアと内部タイマーを使用することです。このようなアプローチは実行可能ですが（元のIBM PCはそのように機能しました）、特に安定しているわけではありません。また、オペレーティングシステムがシャットダウン、ハング、またはクラッシュした時点で日付/時刻の追跡が失われます。

リアルタイムシステム

「リアルタイム」という用語がコンピューターシステムまたはアプリケーションに適用されるとき、それは非常に短い決定論的な時間で、実世界のイベントに応答するシステムを表します。同時入力の。リアルタイムシステムは、ロボット、シミュレーション、ゲームなどの機械制御などに使用されます。リアルタイムアプリケーションは現在の時刻と日付の情報を利用できますが、アプリケーションは現在の時刻と日付を利用しているという理由だけで「リアルタイム」ではありません。

リアルタイムクロックと高解像度タイマー

前述のように、リアルタイムクロックの目的は、現在の日付と時刻を、通常は秒単位で確実に追跡することです。良いものは、ドリフトが最小限に抑えられます（毎日、秒が増減します）。通常、リアルタイムクロックは高解像度ではありません。ベースクロックは、最新のCPUクロックと比較して非常に遅いことがよくあります。これは、ホストコンピューターの電源が長時間オフになった場合でもクロックが確実に時間を維持できるように、電力消費（独立した電源のドレイン）を最小限に抑えるためです。

高解像度のタイマーは、現在の時刻や日付には関係ありません。その目的は、マイクロ秒またはそれ以下の精度で時間間隔を測定することです。これを実現するには、安定した高周波クロック（通常はコンピューターシステムクロック）に基づいている必要があります。通常、高解像度のタイマーは、長時間にわたるドリフトには関係しません。通常の目的は、短時間にわたる時間測定だからです。高解像度のタイマーは、ホストコンピューターの電源がオフのときに実行する仕事がないため、リアルタイムクロックと同じ電力消費の懸念はありません。

ほとんどのシステムでは、他の形式の時間管理に対するRTC周辺機器の唯一の本当の利点は、システムの残りの部分がスリープ状態になったとき、または場合によっては完全に電源がオフになったときにRTCの時間測定が影響を受けないことです。多くのRTCペリフェラルは、実際には、おおよその時刻を記録する以外のほとんどの目的で非実用的になるように設計されています。たとえば、多くのRTCペリフェラル（おそらく大多数ですが、おそらく過半数ではない）は、1秒単位でのレポート時間に制限されており、それらの多くは、アラームまたは場合によっては、単に時間を読み取ろうとしてもです。そのため、RTCを使用する通常の方法は、起動時に値をより便利なクロックに単純にコピーし、「ウォールタイム」が設定されている場合は常に設定することです。

また、最初と最後の間に1/32768秒以上経過しない限り、4つの連続した読み取りには、一致する（したがって正しい）2つが含まれることが保証されます。アラームを設定すると、偽のウェイクアップイベントが生成される場合がありますが、シーケンスは次のとおりです。

• ウェイクアップラッチからの割り込みを無効にする
• 現在よりも先に最大0x7FFFFFFFティック（約9時間）のウェイクアップ時間を設定します。
• ウェイクアップ回路をリセットする
• 時計を読む
• 新たに読み込まれた時刻が起床時刻に到達したことを示している場合、適切に行動する
• ウェイクアップラッチからの割り込みを有効にする

汎用の計時の使用に適しているように、すべてのエッジケースを十分に簡単に処理する必要があります。残念ながら、何らかの理由で、RTC周辺機器はそのように設計されることはありませんが、代わりにより複雑で有用性が低くなります。

リアルタイムクロックの主な理由は、ある間隔までの正確な時間だと思います。通常のクロックは通常、コンデンサで調整され、クロックタイミング回路のキャパシタンス/抵抗の調整不良、使用されているクロックのタイミングの不確実性など、おそらく制御不能なさまざまな要因に基づいて、周波数に大きな不一致が生じる可能性がありますパフォーマンスのために決まった目的を果たします。また、多くの場合、エラーを引き起こす可能性のある時間を分割するためのプログラマブルロジックがあります。

通常、RTCにはタイマーやウォッチドッグなどを接続できます。RTCを組み合わせることで、さまざまな処理やコードとの位相を維持できる定期的で正確な間隔で実行されるという保証または良好な仮定が得られます。通常の時計では簡単に取得できません。または、クロックが正確であることを本番環境で非常に注意する必要があります。オーディオや、高速システムクロックの代わりにrtcを使用する必要のないものなどを確認できます。

RTCが何を意味するのかについては、私自身で確実に言うことはできません。Linuxは組み込みの世界で広く普及しているツールですが、すべてのリアルタイムアプリケーションでLinuxがどのように機能するかはわかりません。マルチスレッドは実行時間を非決定的にしますが、ハードウェアがパフォーマンス要件を大幅に超える場合、多くのソリューションはリアルタイムアプリケーションでも正常に動作します。

次に、ミッションクリティカルで低パフォーマンスのアプリケーションがあります。ここで望ましいことの1つは、確定的であり、多くの場合、複雑さの低いソリューションです。ここで、RTCは明らかに使用できます。Linuxは、それに結合された割り込みへの特別なアクセスを提供する場合があります。決定論的なリアルタイムでは、rtcだけでなく、割り込みまたはosアクセスが必要なようです。

インターネット上の他のコンピューターとの安全な通信に依存している場合は、リアルタイムクロックが必要になります（100％である必要はありませんが、ローカル時間の参照がない場合は、他のものを信頼する必要があります。日付がわからない限り、証明書を信頼します）。

そのため、すべての「リアルタイム」システムに必要なわけではありません。ただし、アプリケーションによっては、低電力状態になった後に適切な時間修正を取得する最もエネルギー効率の良い方法としてRTCが必要な場合があります。