時間管理：時間スケール、補正、および読み取り

接続タイムアウト、サスペンド後の資格情報期限切れ、マシン間ログのソートに必要なものは、同じタイムラインではない。

時間管理は異なる問題に答える必要がある：ログが何日に発生したか、操作が実際にどれくらい経過したか、システムのサスペンドがタイムアウトにカウントされるか、そして2台のマシンのタイムスタンプを比較できるか。クロックの選択は、まずこれらの意味論的な問題に答え、次に読み取りコストを考慮する。

1. 意味論に基づいたクロックの選択

MONOTONIC の単調性は通常、隣接する読み取りで等しくなることを許可するが、読み取るたびに厳密に増加することを保証するものではない。それは「NTP 調整の影響を受けない」ことを意味せず、さらにカウンターが永遠に周波数誤差を持たないことを意味するものでもない。RAW もまた、マシン間で比較可能な UTC ではなく、無条件で最も正確なビジネスクロックと呼べるものでもない。API の意味論は clock_gettime を参照。

2つの期限の例

接続確立には最大5秒待つ必要があるが、通常は MONOTONIC の期限切れを使用する必要がある。これは、管理者がカレンダークロックを1分戻した際に、さらに1分待つことにならないようにするためである。認証資格情報がコンピュータのサスペンド後も経過時間に基づいて期限切れになるべき場合、BOOTTIME または正しく同期された絶対期限を組み合わせて設計する必要がある。

MONOTONIC の値をディスクに保存し、再起動後に比較を続けることは通常意味をなさない。Aマシンの MONOTONIC を Bマシンの値から減算しても、ネットワークレイテンシは得られない。分散ログには、カレンダー時間、誤差評価、因果関係の識別など、共同での解釈が必要である。

ウェイクアップ時間を先に進め、その後サスペンドまたはジャンプする壁掛け時計を跨ぐ。以下では、「クロックが期限を過ぎたこと」と「コールバックが実行されたこと」を分離し、期限切れをその時点で実行中であると誤解しないようにする。

2. Timekeeping はどのようにカウントを時間に変換するか

最近更新されたカウントと基準時間を維持し、新しいカウントを読み取った後に経過量を計算する。簡略化された整数変換は以下の通りである：

delta_ns ≈ ((cycles_now - cycles_last) & mask) × mult >> shift

mask は有限幅のカウンターラップを処理し、mult/shift は高価な計算を減らす。ただし、実際の処理系では中間のオーバーフローを回避し、異なる基準と補正を処理する必要があり、この式を完全なドライバコードとして扱うことはできない。周波数の維持は、ラップを区別するのに十分でなければならず、無限に更新しないことはできない。

時間の読み取りは、次の tick を待つ必要がない。現在のカウント差から、基準以降の経過時間を推定できる。timekeeper の実際の構造はバージョンによって変化し、それを維持する更新パスは「すべての hrtimer 割り込みがすべてのクロックを完全に再計算する」ものではない。下層の責任は timekeeping を参照。

なぜ一貫性のあるスナップショットが必要なのか

基準、mult、shift などのフィールドは共同で解釈される必要がある。更新前の基準と更新後の変換パラメータを読み取った場合、結果は誤っている可能性がある。したがって、読み取りパスはシーケンス検証などのメカニズムを使用し、並列更新が発見されると再試行する。これは、カウンターを1回読み取るだけで完了するものではない。

3. NTP：時間サーバー、ユーザーランド制御、およびカーネル補正

chronyd/ntpd などのユーザーランドサービスはネットワーク時間ソースと推定を処理し、カーネルは adjtimex/clock_adjtime などのインターフェースを通じて対応する周波数と位相の調整を実行する。カーネルの ntp.c は、独立してネットワークに接続された「NTP デーモン」ではない。

RAW と MONOTONIC の長期差の変化は補正の手がかりを提供できるが、測定ノイズとクロックの選択を考慮する必要がある。

struct timex のフィールド単位は flags/mode によって異なる。例えば、周波数は規定されたスケーリング単位を使用し、offset のマイクロ秒/ナノ秒の意味は状態による。adjtimex のすべてのフィールドを通常のナノ秒と ppm として注釈付けることはできない。adjtimex を参照。

同期状態と誤差範囲は一緒に読む必要がある

同期サービスが同期を報告しても、2台のマシンの時間が完全に同一であることを意味するものではない。ネットワークパスの非対称性、クロックドリフト、サンプリング、およびハードウェアにより誤差が発生する。ミリ秒未満の間隔をマシン間で判断する場合、誤差範囲を結論に組み込む必要がある。

4. TAI、UTC、およびうるう秒

TAI と UTC のオフセットは歴史的なうるう秒によって決定され、長期的な知識記事の中で特定の値を永久定数として記載すべきではない。Linux の CLOCK_TAI は、システムが正しいオフセットを設定していることに依存する。オフセットが設定されていない、または誤っている場合、呼び出しが成功しても、信頼できる TAI が返されるとは限らない。

TAI 時間スケールには、UTC のうるう秒挿入のような同様の不連続処理はないが、カーネルの時間補正と設定変更は実際の観測に影響を与える可能性がある。leap smear を使用する時間サービスは、ウィンドウ内で意図的に厳密な UTC から外れる。異なる smear 戦略を混合したマシンは、タイムスタンプが直接一致すると仮定できない。

プロトコルは、時間スケール、単位、およびうるう秒/補正戦略を明確にする必要があり、単に整数を渡して timestamp と命名するだけでは不十分である。

5. PTP、PHC、およびハードウェアタイムスタンプ

PHC はデバイス上の PTP ハードウェアクロックであり、Linux は /dev/ptpN を介してアクセスを提供できる。ネットワークカードは、送受信ハードウェアに近い位置でタイムスタンプを打つことで、ソフトウェアキューイングに起因する不確実性を減らす。PTP プロトコルおよびユーザーランドサービスは、これらの測定を使用して対応するクロックを同期する。

ネットワークカードの PHC とシステムの REALTIME は異なるクロックオブジェクトであり、ptp4l がインストールされただけでは、両者が自動的に完全に一致することが保証されるものではない。phc2sys などのツールは、対応するクロック間の同期を担当し、設定ではどちらが参照であり、どちらが調整されるかを説明する必要がある。

SO_TIMESTAMPING のソフトウェア、変換、および生のハードウェアタイムスタンプフィールドとフラグは、インターフェースに従って解釈する必要がある。ナノ秒の保存単位は、ナノ秒単位の同期精度を保証するものではなく、実際にはネットワークカード、スイッチ、リンク、設定、温度などに影響される。PTP clock および ネットワークタイムスタンプ を参照。

6. vDSO は高速読み取りパスであり、新しい時間スケールではない

カーネルは vDSO ELF をユーザープロセスにマップし、libc は其中的なクロック関数を呼び出すことができる。カーネルが公開するデータページとユーザーランドで読み取りが許可されたカウントソースと組み合わせることで、一般的なクロッククエリはカーネルへの陥落を回避できる。

これは依然としてカーネルが維持する時間パラメータと一貫性プロトコルに依存している。対象アーキテクチャ、clocksource、または clock ID が高速パスでサポートされていない場合、syscall にフォールバックする可能性がある。strace で clock_gettime syscall が見えないからといって、プログラムが時間を読んでいないことを意味するものではない。

syscall によるカーネルへの入り込みは特権レベルの変換を伴い、必ずしもタスクコンテキストスイッチが発生するわけではない。読み取りコストは測定する必要があり、vDSO が 20 ns、syscall が 100 ns であると固定して約束することはできない。x86 のパスを、ARM の __arch_counter_get_cntvct() を呼び出すかのように偽装して記述してはならない。vDSO を参照。

7. ハードウェアの能力が最終的な時間の品質を意味するわけではない

TSC、HPET、ACPI PM timer、ARM Generic Timer、および仮想化 paravirtual clock は、異なるアクセス、周波数、および安定性の属性を持つ。TSC の invariant などの能力は安定した計時に役立つが、CPU 間の同期、ファームウェア、仮想化、および移行にはカーネルの判断が必要であり、CPU 周波数の逆数を測定精度として直接使用することはできない。

clocksource watchdog およびカーネルの検証により、信頼できないソースのいくつかを発見し、切り替えることができる。「理論的により高速な」ソースを強制的に選択すると、信頼性が低下する可能性がある。現在の設定を理解するための第一歩は、読み取り専用で観察することである。

from pathlib import Path
import time

root = Path('/sys/devices/system/clocksource/clocksource0')
for field in ('current_clocksource', 'available_clocksource'):
    try:
        print(field, (root / field).read_text().strip())
    except OSError as exc:
        print(field, type(exc).__name__)

names = ('CLOCK_REALTIME', 'CLOCK_MONOTONIC', 'CLOCK_MONOTONIC_RAW',
         'CLOCK_BOOTTIME', 'CLOCK_TAI')
for name in names:
    if not hasattr(time, name):
        continue
    clock = getattr(time, name)
    try:
        print(name, 'ns=', time.clock_gettime_ns(clock),
              'resolution_s=', time.clock_getres(clock))
    except OSError as exc:
        print(name, type(exc).__name__)

start = time.clock_gettime_ns(time.CLOCK_MONOTONIC)
time.sleep(0.02)
elapsed = time.clock_gettime_ns(time.CLOCK_MONOTONIC) - start
assert elapsed >= 20_000_000
print('observed sleep elapsed_ns=', elapsed)

これらのクロックは順次読み取られるため、隣接する印刷値の差を正確なオフセットとして直接使用することはできない。この例では、クロックの変更やサスペンドのトリガーも行わない。clock_getres() は分解能情報を提供するが、現在の UTC 誤差や実際のウェイクアップジッターを証明するものではない。

8. 時間測定の実行順序

まず、比較対象が同じ時間スケールおよび同じマシン/起動サイクルであることを確認する。次に、サスペンド、補正、および仮想化の一時停止がカウントされるべきかどうかを確認する。周期的な実行が必要な場合は、絶対/相対期限と補走ルールを確認し、マシン間の比較が必要な場合は同期誤差を確認し、最後に vDSO およびハードウェア読み取りのオーバーヘッドを分析する。

関連リンク：クロックとタイマー、同期メカニズム。