通常、実時間はシステム RTC によって提供されます。これはほとんどの場合、ミリ秒の範囲までの時間を提供するだけで、通常は 10 ~ 20 ミリ秒の粒度です。ただし、 gettimeofday()の解像度/粒度は、多くの場合、数マイクロ秒の範囲であると報告されています。マイクロ秒の粒度は別のソースから取得する必要があると思います。
gettimeofday() のマイクロ秒の解像度/粒度はどのように達成されますか?
ミリ秒までの部分が RTC から取得され、ミリ秒が別のハードウェアから取得される場合、2 つのソースの位相に関する問題が発生します。2つのソースはsynchronized
何らかの方法である必要があります。
これら 2 つのソース間の同期/位相はどのように達成されますか?
編集: amdn が提供するリンク、特に次のIntelリンクで読んだことから、ここに質問を追加します。
gettimeofday()
マイクロ秒領域で解像度/粒度を提供しますか?
編集 2: amdns の回答をいくつかの読み取り結果で要約します。
Linux は、起動時にリアルタイム クロック (RTC) のみを使用して、Timestampcounter (TSC) などの高解像度カウンターと同期します。起動後、gettimeofday()
TSC 値とこのカウンターの頻度に完全に基づく時間が返されます。TSC の初期値はfrequency
、システム時刻を外部時刻ソースと比較することによって修正/較正されます。調整は、adjtimex()関数によって実行/構成されます。カーネルはフェーズ ロック ループを操作して、時間の結果が単調で一貫していることを確認します。
このようにしgettimeofday()
て、マイクロ秒の分解能があると言えます。最新の Timestampcounter が GHz 領域で実行されていることを考慮すると、取得可能な解像度はナノ秒領域になる可能性があります。したがって、この意味のあるコメント
/**
407 * do_gettimeofday - Returns the time of day in a timeval
408 * @tv: pointer to the timeval to be set
409 *
410 * NOTE: Users should be converted to using getnstimeofday()
411 */
Linux/kernel/time/timekeeping.cにあります。これは、後の時点でさらに高い解像度の機能が利用可能になる可能性があることを示唆しています。現在getnstimeofday()
、カーネル空間でのみ利用可能です。
ただし、これを正しく行うために関連するすべてのコードを調べると、不確実性に関するかなりの数のコメントが表示されます。マイクロ秒の分解能が得られる可能性があります。この関数gettimeofday()
は、マイクロ秒領域の粒度を示すことさえあります。ただしdrift
、TSC 周波数を正確に補正できないため、その精度については深刻な問題があります。また、Linux 内でこの問題を処理するコードが複雑であることは、実際にはそれを正しく行うのが難しすぎることを示唆しています。これは特に、Linux が実行されるはずの膨大な数のハードウェア プラットフォームだけが原因ではありません。
結果: マイクロ秒の粒度で単調な時間を返しますが、それが提供する時間は、他の時間ソースとgettimeofday()
位相が一致することはほとんどありません。one microsecond