概要

  • linuxptp は、IEEE 1588 Precision Time Protocol を Linux 上で実装した、広く利用されているオープンソースソフトウェアである。ハードウェアクロック、パケットタイムスタンプ、外部イベント、クロック調整のための最新カーネルインターフェースを基盤とする。
  • 各ツールが時刻同期を分担する。ptp4lは PTP の状態管理と遅延測定、phc2sysはハードウェアクロックとシステム時刻の接続、ts2phcは外部タイムスタンプによるクロック同期を担い、管理ツールは設定と状態を表示する。
  • 精度は経路全体の特性である。デーモンが正しくても、非対称な経路、不安定な発振器、誤った UTC オフセット、低品質なタイムスタンプ用ハードウェア、偽装された GNSS 基準、互換性のないプロファイル設定までは補えない。
  • 公開リリース情報は分散している。SourceForge は Richard Cochran をメンテナーとし、2023年12月のバージョン 4.2 を今も最新ダウンロードとして表示する一方、活発に保守されているソースツリーはバージョン 4.4 を名乗り、2026年の変更を含む。運用者はリリース成果物と現在の開発状況を区別する必要がある。

通常のタイムスタンプを信頼できなくなる地点から高精度時刻は始まる

多くのコンピューターは、ログ、証明書、人間の予定には十分な精度で時刻を維持する。水晶発振器のずれをネットワークプロトコルが定期的に補正し、多くの用途では数ミリ秒の誤差が許容される。しかし、通信同期、産業制御、電力システム、市場インフラ、一部のデータセンター処理では、はるかに厳しい限界と、その限界を外れたことを示す証拠が必要になる。

難しさは、より良い時計を読むことだけではない。時刻は連鎖を通る。基準源が周波数と位相を供給し、受信機と発振器がローカルクロックを作る。ハードウェアがパケットの境界通過時刻を記録し、ネットワークがキューやスイッチを介して時刻メッセージを運ぶ。サーボがオフセットと周波数誤差を推定し、ソフトウェアがハードウェアクロックまたは OS クロックを補正し、アプリケーションが結果を使う。

誤差は各段階で入る。アンテナケーブル遅延は GNSS 基準を偏らせ、往路と復路のネットワーク遅延は異なり得る。ドライバーが一部のタイムスタンプモードしか公開しない場合もあり、基準喪失時にはローカル発振器が急速にずれることもある。古い UTC オフセットは、安定して見える大きな誤差を生む。デーモンが選択済みマスターを報告していても、侵害または劣化した基準に従っている可能性がある。

linuxptp は Linux 上でこの連鎖を調整する。IEEE 1588 規格そのものでも、カーネルの PTP Hardware Clock サブシステムでも、グランドマスター機器でも、NTP 実装でもない。最新の Linux 時刻 API を使うユーザー空間デーモンとツールを提供する。Linux に明確に重点を置き、旧式 API や他の OS との互換性を主要目標とはしていない。

この重点は重要である。高精度時刻には、ユーザー空間、カーネル、デバイスの密接な統合が必要だ。ハードウェア差を過度に隠す移植層は、運用者が把握すべきタイムスタンプ位置や調整能力を見えにくくする。linuxptp は、ドライバーが標準カーネルインターフェースを通じてクロックを公開することを前提に、プロトコル状態と制御ループを構築する。

したがってプロジェクトの価値は構造にある。運用者は、時刻同期対応 NIC やカード、Linux サーバー、PTP プロファイル、選択した基準源を組み合わせられ、機器ごとに閉鎖的なソフトウェア一式を買う必要がない。検査可能性と供給元の選択肢を得る一方、商用時刻同期機器に含まれがちな校正、検証、監視を自ら担う。

高精度時刻インフラは通常のサービスソフトウェアとは異なる形で故障する。停止したデーモンは見えるが、もっともらしい誤差を抱えたまま動く時計は、全プロセスが正常に見える中でイベント順序を壊し得る。目標は可用性だけでなく、既知の不確かさの範囲内で正しい時刻を保つことだ。

linuxptp が調整できるようになる前に、Linux は共通のハードウェアクロックインターフェースを作った

ハードウェアタイムスタンプは linuxptp より前から存在したが、機器固有インターフェースのため汎用ソフトウェアの構築は難しかった。Linux の PTP Hardware Clock クラスにより、ドライバーは/dev/ptp0などを通じてクロックを標準的に公開できるようになった。ユーザー空間はベンダー固有ツールではなく、一般的なクロック API と専用 ioctl でクロックを読み取り、調整できる。

カーネルはSO_TIMESTAMPINGによるパケットタイムスタンプも提供する。ドライバーと機器は、選択したパケットの送受信を MAC または PHY 境界近くで記録でき、割り込み、スケジューリング、ユーザー空間処理による変動を減らす。ただし境界位置は重要で、MAC と PHY のタイムスタンプでは物理経路に含まれる部分が異なる。

外部タイムスタンプ入力により、PTP Hardware Clock は 1 秒周期パルスなどの物理イベント到着を記録できる。周期出力は他の機器を駆動でき、PPS 統合、クロスタイムスタンプ、クロック調整 API はデバイス時刻とシステムを接続する追加要素となる。

これらのインターフェースはカーネルと linuxptp の責任を分ける。カーネルはクロック、タイムスタンプ、調整機構を公開し、ドライバーはデバイス能力をそこへ対応付ける。NIC、PHY、時刻同期カードがカウンターとタイムスタンプ用ハードウェアを持ち、linuxptp がプロトコル状態を実行して補正を計算し、クロックを調整する。

標準インターフェースは移植性を高めるが、機器間の同等性は保証しない。必要な PTP イベントをすべて記録し、設定可能な端子を公開する NIC もあれば、一部のみ対応するものもある。ファームウェアがフィルターや校正を変える場合や、API を実装したドライバーに欠陥がある場合もある。運用者には、正確なハードウェア、ファームウェア、カーネル版に結び付いた能力一覧が必要だ。

カーネル境界はセキュリティと運用にも影響する。直接のクロック調整には権限が必要で、PHC にアクセスできるプロセスはグランドマスターを変更できなくても時刻を乱せる。機器追加でデバイス名が変わることがあり、コンテナは基礎となる PHC に直接触れずシステム時刻だけを見る場合がある。運用自動化では、正しいデバイスを正しい時刻処理へ割り当てなければならない。

linuxptp はこれらの最新 API を基盤に登場し、2011年10月1日に SourceForge の公開プロジェクトとして登録された。ソース履歴はそれ以前にさかのぼる可能性があるが、この日付は公開プロジェクト基盤の開始を示す。現在の Linux 時刻機構へ依存する設計により、互換性対応の寄せ集めではなく一貫したツール群が生まれた。

結果として、ハードウェアとソフトウェアの共同設計が成立した。カーネルが制御面を標準化するため、オープンなデーモンは多数の機器を支援できる。ただし最高精度は機器実装に依存する。オープン性はソフトウェアのベンダーロックインを減らすが、すべての発振器やタイムスタンプ装置を同等品にはしない。

ptp4lは従うべきクロックを決める状態機械を実行する

ptp4lはツール群の中心デーモンである。PTP ドメインに参加し、プロトコルメッセージを交換し、経路遅延を測定してクロックを同期させる。通常クロック、境界クロックとして動作でき、対応状況と設定によっては透過クロックにもなれる。

PTP ノードはクロック品質、優先度、識別子を通知する。Best Master Clock Algorithm はそれらを比較し、どのクロックをグランドマスターにするか、各ポートをマスターまたはスレーブのどちらにするかを決める。単に最も正確な発振器を選ぶわけではない。運用者の優先度やプロファイル規則で特定の基準が優先され、トポロジーと許可された役割も選定を制約する。

ポートがマスターに従うと、Sync と関連メッセージが時刻情報を提供する。1 ステップ方式では正確な送信時刻をイベントメッセージへ入れ、2 ステップ方式では別メッセージで送る。遅延メッセージはパケットの経路時間を推定し、デーモンは観測値を組み合わせてクロック間オフセットを求める。

推定は遅延に関する仮定へ依存する。多くの計算は往路と復路の遅延が十分に対称だとみなす。一方向が一貫して長ければ、往復時間の半分という推定には偏りが生じる。キュー、経路変更、異なる光ファイバー、スイッチの挙動はいずれも非対称性を作る。プロトコルは一部を測定・補正できるが、隠れた物理差をすべて推定できない。

ptp4lはサーボで位相と周波数を調整する。比例積分制御、線形回帰などの方式では、収束速度とノイズの間に取引関係がある。大きな初期誤差はステップで補正し、定常時の誤差はアプリケーションへの影響を避けるため徐々に調整することが多い。積極的なサーボはパケット遅延変動を追い過ぎ、保守的なサーボは復旧に時間がかかる。

ポート状態とマスター選択は、想定するだけでなく監視しなければならない。スレーブは同期状態を保ったまま別のグランドマスターへ切り替わり得る。新しい基準は信頼性が低いか、想定外の経路上にあるかもしれない。切り替え後の良好なオフセットが、冗長性が最後の一つへ縮小した事実を隠す場合もある。

設定にはプロファイル、転送方式、ドメイン、優先度、遅延、サーボの選択が含まれる。双方が IEEE 1588 対応をうたっても、一方がエンドツーエンド遅延、他方がピアツーピア遅延を使う場合や、プロファイルごとにメッセージ頻度と役割が異なる場合は相互運用できない。「PTP 有効」は相互運用性を意味しない。

したがってptp4lは制御プロトコルを実装するもので、普遍的なクロック品質保証ではない。設定規則の下で見える最良の基準を選び、クロックを同期できるが、候補、トポロジー、ハードウェアによってその選択を意味あるものにする責任は運用者にある。

エンドツーエンド遅延とピアツーピア遅延は異なるネットワーク条件を表す

PTP では一般にエンドツーエンドまたはピアツーピアの遅延測定を使う。両者は置き換え可能ではなく、導入時には機器とプロファイルの想定を一致させる必要がある。

エンドツーエンド方式はネットワーク経路全体についてスレーブとマスター間の遅延を測る。遅延要求・応答メッセージで往復時間を推定する。通常のスイッチでも動作するが、キュー遅延と経路非対称性が経路全体で累積し、中継機器が滞留時間を公開しないこともある。

ピアツーピア方式は、隣接する PTP 対応機器間のリンクを測る。透過クロックはイベントメッセージがスイッチ内に滞在した時間を計上し、補正値を加えられる。この方式には経路上で参加するインフラと一貫した対応が必要だ。

境界クロックは一つのポートで時刻を終端し、別のポートで再生成する。上流から同期したローカルクロックを持ち、下流ではマスターとして動く。誤差を抑え、ドメインを拡張できる一方、発振器、サーボ、障害点を一つ追加する。透過クロックは時刻源にはならず、滞留時間を測定・通知して端点による補正を可能にする。

通常クロックは一つの PTP ポートを持ち、マスターまたはスレーブになる。グランドマスター機器も、高品質な基準と発振器を備えた通常クロックだが、プロトコル上の役割だけではホールドオーバー性能や基準の完全性は分からない。

適切な設計はトポロジーで決まる。通信網では経路上の全面的な時刻対応と慎重に設計した境界クロックが必要な場合がある。産業ネットワークでは管理されたドメイン内でピア遅延を使える。データセンターではスイッチと NIC の能力に合うプロファイルを選べる。

設定を誤ると、メッセージを交換しながら誤差予算を満たさないシステムになる。ノードが誤った遅延方式でマスターへ同期したり、一つの経路に透過クロックがなかったり、負荷分散で異なる遅延の経路間を移動したりする。体系的な非対称性が残っていても、デーモンは安定状態を報告し得る。

試験ではソフトウェアクロック二つのオフセットだけでは不十分である。校正済み計測器、ループバック、PPS 比較、経路分析を用いて誤差の流入点を特定する。ケーブル長、SFP、スイッチのファームウェア、タイムスタンプ位置も試験記録に含めるべきだ。

linuxptp はこれらの構成に必要なプロトコル制御を公開するが、物理ネットワークを認証するものではない。この境界が、ソフトウェアが無償でもプロジェクト支援と運用者の専門知識が価値を持つ理由の一つである。

phc2sysはネットワーク側クロックをアプリケーションが読む時刻へ接続する

NIC の PTP Hardware Clock がネットワークへ精密に同期していても、Linux のシステム時刻は誤っていることがある。一般的なアプリケーションが読むのは/dev/ptp0ではなくCLOCK_REALTIMEだ。phc2sysは一方のクロックを他方へ同期させ、この隔たりを埋める。

方向が重要である。一般的なスレーブホストでは、ptp4lが NIC の PHC をネットワークから同期し、phc2sysがその PHC からシステムクロックを同期する。グランドマスター設計では外部基準が PHC を同期し、システムクロックがそれに従う場合がある。方向を逆にするとクロック同士が競合したり、精度の低い基準が高品質なクロックを制御したりする。

自動モードはptp4lの状態から関係を導き、手動ミスを減らせる。複雑なホストには複数の NIC PHC とインターフェースがあり、どのポートが有効で、どのクロックを基準にするか追跡する必要がある。機器交換やインターフェース名変更で、安定して見えた前提が崩れることもある。

時刻尺度もリスクになる。PTP 時刻と UTC は関係するが同一ではない。現在の UTC オフセットと閏秒状態を一貫して扱わなければならない。古いオフセットは秒単位の誤差を生み得るが、サーボは安定した関係を報告する。単調な補正を受けていても、アプリケーションの市民時刻が誤る可能性がある。

システムクロックのステップ変更は、時刻が後戻りしないと仮定するアプリケーションを乱す。徐々に補正すれば連続性は保てるが、大きな誤差の解消には時間がかかる。起動、切り替え、復旧の方針が必要であり、通信無線とデータベースやログでは適切な動作が異なる。

phc2sysは設定と対応状況により複数 PHC も同期でき、境界クロックホストや複数ポートのシステムに有用である。達成精度はクロスタイムスタンプ品質とデバイス能力に左右される。

監視では基準側と同期先、オフセット、周波数調整、状態、最後の成功時刻を表示すべきで、単一の「同期済み」フラグでは足りない。基準変更、サーボ飽和、UTC オフセット不整合を警告する必要がある。

このツールは linuxptp が単一デーモンではなく一式である理由を示す。ネットワークプロトコル状態とアプリケーションが見る時刻は別の制御ループであり、前者が正しくても後者は失敗し得る。高精度時刻インフラでは基準から利用者まで全経路を追跡しなければならない。

ts2phcは物理基準信号を Linux のハードウェアクロックへ取り込む

グランドマスターや時刻同期カードは、GNSS などの高品質基準から 1 秒周期パルスを受けることが多い。パルスは正確な位相を与えるが、それだけでは完全な日付と時刻を示さない。別の時刻情報が、パルスの示す秒を特定する。

ts2phcは対応する PTP Hardware Clock の外部タイムスタンプ入力を使い、その信号からクロックを同期する。PHC がハードウェア近くでイベントを記録するため、ユーザー空間の割り込みタイムスタンプに伴う不確かさを大幅に避けられる。一つの物理基準を複数のデバイスクロックへ接続することもできる。

ハードウェア対応が決定的である。時刻同期カードまたは NIC は、設定可能な端子と外部タイムスタンプ機能をカーネルドライバー経由で公開しなければならない。極性、チャンネル対応、エッジ選択は配線と一致する必要がある。入力にすべき端子を出力に設定すると、ソフトウェアが動いていても有効な証拠は得られない。

ケーブル遅延と受信機の挙動は校正が必要だ。長いアンテナまたは PPS ケーブルは固定オフセットを加え、温度や部品劣化で変化する。基準が安定していても偏り得る。校正値はハードウェアのシリアル番号や設置情報と共に記録すべきだ。

GNSS は世界的に利用可能な絶対時刻を提供する一方、セキュリティと可用性のリスクを伴う。妨害は信号を失わせ、偽装はもっともらしい偽時刻を示す。アンテナ障害、マルチパス、受信機故障も品質を下げる。ts2phcは受け取った入力にクロックを従わせるが、追加証拠なしに衛星信号が正しいかは判断できない。

複数衛星群対応の受信機、アンテナ監視、基準比較、ホールドオーバーは耐障害性を高める。別の GNSS 経路、地上サービス、原子基準など独立した基準は不一致を明らかにできる。選択や投票の仕組みは linuxptp の外部に置かれる場合がある。

外部タイムスタンプは GNSS 以外の研究所・産業基準からも得られる。構造は一般的で、ハードウェアが物理イベントを記録し、ソフトウェアがそれに基づいてクロックを制御する。精度は基準、入力経路、デバイスに依存する。

ts2phcにより、オープンな Linux ホストは従来専用グランドマスター機器に結び付いていた設計へ参加できる。その代わり運用者は、機器ベンダーが統合・認証するはずのアナログおよび物理的な詳細を自ら設計する。

timemasterは一つの万能プロトコルを宣言せず、PTP と NTP を調整する

PTP と NTP は重なるが異なる問題を解く。NTP と chrony などの実装は、遅延が変動する広域網上の一般的なシステム時刻に有効である。PTP は特にハードウェアタイムスタンプと設計済み経路を使う場合、より高い精度とプロファイル固有環境を対象とする。

ホストは両方を必要とする場合がある。PTP をローカルな高精度基準にし、NTP を予備または配布手段にできる。timemasterは linuxptp と chrony または ntpd を調整し、デーモン同士が同じクロックを奪い合わないよう設定を生成・管理する。

複数基準を組み合わせるには優先順位と障害方針が必要だ。到達性評価の変化だけで NTP が正常な PTP グランドマスターからシステムを引き離すべきではない。一方、選択したマスターが劣化し、サーボを信頼できなくなった後まで PTP を優先すべきでもない。

クロックループは特に危険である。システム時刻が PTP 基準に影響し、その基準が再びシステム時刻を同期するなら、見かけ上の冗長性は循環している。ネットワーク図が経路依存関係を示すように、トポロジー文書は時刻依存関係も示すべきだ。

chrony はさまざまな構成で PHC または PPS 基準を利用できる。正確な統合方法は用途とハードウェアに依存する。timemasterは設定負担を減らすが、組織の基準階層までは決められない。

NTP には異なるセキュリティと運用の仕組みもある。認証、サーバー多様性、インターネット到達性はローカル PTP を補完できるが、精度と誤差モデルは異なる。切り替え後に精度が下がっても正しい時刻を保てるなら、精密だが偽の基準へ従い続けるよりよい場合がある。

混合プロトコル設計では状態ごとの誤差予算を示すべきだ。アプリケーションは PTP 下で通常運用し、NTP 下では機能を制限し、不確かさが限界を超えたら停止できる。この条件がなければ、デーモン上は成功した切り替えでもサービス要件に違反し得る。

linuxptp が chrony や ntpd と共存する姿勢は、高精度時刻がプロトコル競争ではなく構造設計であることを示す。正しい組み合わせは要件と障害モデルで決まる。

管理ツールはクロック状態を検査可能にするが、意味まで自動説明しない

ツール群には、PTP 管理メッセージ用のpmc、ハードウェアクロックの直接確認・調整用のphc_ctl、ハードウェアタイムスタンプ設定用のhwstamp_ctlがある。運用者は、時刻挙動を決める状態と能力へアクセスできる。

pmcはクロック識別子、ポート状態、優先度、時刻特性などのデータセットを照会できる。ノードが誤ったグランドマスターへ従う場合や、プロファイル値が想定と違う場合に管理面の可視性は不可欠だ。優先度やデータセットの書き換えはドメイン選択を変え得るため慎重に扱う必要がある。

phc_ctlは PHC を直接操作し、診断や実験室試験に役立つ。本番環境での手動調整は制御ループを乱し得るため、管理者アクセスを制限し、変更を記録すべきだ。

hwstamp_ctlはドライバーインターフェース経由で NIC のタイムスタンプを設定する。対応するフィルターとモードは機器ごとに異なる。要求が広いフィルターへ丸められたり、拒否されたり、ファームウェア固有の挙動で受理されたりする。実際の設定を読み戻し、試験すべきである。

ログと管理データには文脈が必要だ。基準の識別子、遅延方式、サーボ状態がないオフセット値は誤解を招く。基準変更後の小さなオフセットが多様性喪失を隠すことがあり、計画切り替え後の大きな一時誤差は用途の予算内で回復するなら許容されることもある。

時刻同期の監視データは、瞬間的な画面より時系列で役立つことが多い。周波数調整、経路遅延、グランドマスター識別子、GNSS 状態、発振器温度、パケット数は、オフセットが閾値を超える前にずれを示せる。

監視経路自体にも独立検証が必要だ。同じ誤ったシステムクロックでアラームを記録すると、イベント順序が分かりにくくなる。高保証環境では外部比較やハードウェア信号が必要な場合がある。

オープンなツールは状態を自動処理へ公開するが、普遍的な監視データ形式や障害対応モデルを作るわけではない。下流プロジェクトと運用者が、プロファイルと用途に合う指標、警告、対処を決める必要がある。

プロファイルは柔軟な規格を具体的な相互運用条件へ変える

IEEE 1588 は意図的に広範で、複数の転送方式、クロック種別、遅延方式、メッセージ頻度、選択動作を支援する。二つの製品が規格を実装していても、意図した時刻システムを構成できない場合がある。プロファイルは用途ごとに選択肢を制限する。

通信分野では、周波数配信用の ITU-T G.8265.1 や位相・時刻用の G.8275.x などを使う。これらは通信網に適したトポロジー前提、メッセージ挙動、クロック品質を定義する。経路上の全面対応を求めるものも、部分対応向けのものもある。

電力・産業ネットワークでは、イベント順序と制御要件が異なるため専用プロファイルを使う。generalized PTP とも呼ばれる IEEE 802.1AS は時間依存ネットワーク向けである。各プロファイルは、単なる「PTP 対応」を超える機器動作を求める。

linuxptp は複数プロファイル向けの設定と機能を備える。ソフトウェア対応とはデーモンを参加可能に設定できるという意味であり、製品全体の認証ではない。精度、ホールドオーバー、発振器等級、冗長性、環境性能、ハードウェアタイムスタンプは別の要素だ。

プロファイル適合には版と解釈の問題もある。ベンダーが一部条項のみ対応したり、独自設定を必要としたりする場合がある。異なる機器を組み合わせる運用者は、メッセージ頻度、BMCA 動作、Announce タイムアウト、遅延方式、切り替えを試験すべきだ。

通信構成では PTP と Synchronous Ethernet を組み合わせることが多い。SyncE は物理層で周波数を配り、PTP サーボが補正する周波数誤差を減らす。PTP は位相と時刻を供給する。両者には別々の品質・障害通知があり、その相互作用を管理する必要がある。

SyncE または GNSS の障害後も、発振器がホールドオーバーへ入れば一時的に位相を維持できる。プロファイルが品質通知を定めていても、予算内に留まる時間を運用者が把握しなければならない。ソフトウェアはラベルだけから発振器の劣化や温度特性を推定できない。

プロファイルは導入を規律化する一方、システム全体の認定への依存を高める。linuxptp のオープン実装はプロトコル処理を公開するが、認証と相互運用性には周辺ハードウェアと試験証拠が必要だ。

ホールドオーバーが、基準障害をサービス障害にするか決める

クロックが基準を失っても発振器は動き続ける。ホールドオーバーは、その期間にどれほど正確に時刻を維持できるかを表す。低価格発振器は急速にずれ、恒温槽付水晶発振器はより良い場合がある。チップスケール原子時計は異なる安定性、消費電力、価格を持つ。

linuxptp は状態を報告してクロックを制御できるが、物理発振器の品質は変えられない。継続的な GNSS を前提とするシステムは通常時の仕様を満たしても、妨害時には急速に外れる。強いホールドオーバーがあれば、基準を調査する間もサービスを保てる。

ホールドオーバーの主張には条件が必要だ。温度範囲、経年変化、事前同期時間、継続時間が性能へ影響する。「マイクロ秒級ホールドオーバー」という表現だけでは期間と環境が分からない。ベンダーと運用者は時間に伴う誤差範囲を示すべきだ。

サーボ履歴も重要である。長時間同期していた発振器は、起動直後よりよい周波数推定を持ち得る。温度変化後に突然基準を失うと挙動が異なる。監視では単なる二値のホールドオーバー状態だけでなく、推定値と確信度を保持すべきだ。

基準復旧にも方針が必要だ。戻った GNSS 信号へ直ちにステップ補正するのは、偽装または不整合な信号なら危険である。基準を比較し、オフセットを検証して徐々に補正できる。安全な設計では再取得を自動的な真実ではなく判断として扱う。

冗長グランドマスターは一台への依存を減らせるが、同じアンテナ、電源、衛星群を共有する場合がある。物理的・論理的多様性を記録すべきで、同じ GNSS 分配器や電源に支配される同一ラックの二台は独立していない。

アプリケーションには機能低下時の条件が必要だ。不確かさの増加を許容してタイムスタンプへ示せるものもあれば、順序を保証できなくなる前に停止または切り替えるべきものもある。誤差限界を公開しない高精度時刻は、有効期間を超えてタイムスタンプを使わせる。

ホールドオーバーは時刻同期の費用構造を明らかにする。オープンソフトウェアが無償でも、発振器品質、冗長基準、校正が耐障害性の費用を支配する。linuxptp は部品選択を可能にするが、取引関係はなくせない。

クラウドネイティブな運用自動化が変えるのは導入規模であり、時刻同期の物理法則ではない

通信・エッジシステムでは Kubernetes 上の処理が増えている。OpenShift PTP Operator などは、linuxptp の設定、ノード選択、監視、イベント処理をクラスター向けにまとめる。時刻同期を手編集したホストファイルの集合ではなく、宣言的なインフラにできる。

運用自動化はノードへプロファイルを割り当て、デーモンを管理し、時刻状態をアプリケーションへ公開できる。更新を調整し、高精度を要する処理を適切なクロックのあるハードウェアへ配置できる。イベントを修復や処理移動の契機にもできる。

この抽象化は有用だが誤解も招く。Kubernetes のカスタムリソースは望ましい方針を記述できるが、非対応 NIC にハードウェアタイムスタンプを生み出せない。「PTP 対応」ノードへの配置だけでは、必要なオフセット内にあり、正しいグランドマスターへ従っていることを証明しない。

コンテナ境界ではアクセスが問題になる。デーモンには権限、ホストネットワーク、デバイスへの直接アクセスが必要な場合があり、アプリケーションは PHC ではなくシステム時刻を必要とすることがある。セキュリティ方針はクロック調整権限を制限しつつ、品質情報を読めるようにすべきだ。

クラスター更新ではカーネル、ドライバー、デーモン版が同時に変わる場合がある。時刻同期の退行が、正常に見える基盤更新後のアプリケーション障害として現れ得る。認定にはノードイメージとハードウェアの組み合わせ全体を含めるべきだ。

複数インターフェースのノードは、複数ドメインやプロファイルへ参加できる。運用自動化は正しい PHC を選び、方針の競合を避ける必要がある。インターフェース名だけに基づく検出は、交換や PCI 列挙変更で失敗し得る。

クラウドネイティブ監視は状態集約とイベント通知で規模への対応を改善できるが、ドメイン全体の基準変更時に警告の集中を生むこともある。イベントモデルでは、想定されたトポロジー変更と精度喪失を区別すべきだ。

Operator は時刻設計を置き換えず、その設定を再現・監査可能な仕組みへ移す。linuxptp 全体にも同じ原則が当てはまり、自動化は物理・プロトコル上の前提を隠さず保持するときに価値を持つ。

分散したリリース情報そのものが運用リスクになる

SourceForge はrcochranアカウントの Richard Cochran をメンテナーとし、プロジェクト活動が2026年6月5日に更新されたと表示する。ファイル一覧では2023年12月19日のバージョン 4.2 が今も最新ダウンロードだが、稼働中のソースツリーはバージョン 4.4 を名乗り、2026年のコミットを含む。Network Time Foundation は別にプロジェクト支援、文書、メーリングリスト基盤を提供する。

これらは活発な開発と分散したリリース状況を示すが、導入版または正式版を一つの番号で答えられることを意味しない。公開・導入判断では SourceForge のリリース保管庫、現在のソースツリー、下流パッケージ、ベンダー保守版を区別し、実際に使う成果物の署名とリリースノートを確認すべきだ。

運用者はディストリビューションパッケージやベンダーイメージから導入することが多いため、この違いは重要である。パッケージには、ミラー上の版と一致しないバックポート、スナップショット、セキュリティ修正が含まれ得る。コンテナイメージが最新でもホストドライバーは古い場合がある。版の識別にはソース、ビルド、下流変更を含めるべきだ。

リリースの曖昧さはセキュリティ対応を遅らせる。勧告が上流版を示しても、運用者が見るのはディストリビューション版番号である。組織にはソフトウェア部品表と、修正を導入済みバイナリーへ対応付ける方法が必要だ。

サプライチェーンリスクも生じる。古いミラーや非公式保管庫から取得すると、古いコードを使う可能性が高まる。署名鍵とチェックサムを取得手順へ含め、支援組織とプロジェクトは正式な配布元を明示すべきだ。

長期的な指導者は継続性をもたらすが、公開記録では広範な統治体制より一人の主要メンテナーが明確である。時刻同期ソフトウェアでは小さな演算、時刻尺度、ドライバーの変更が大きな影響を持つため、経験あるレビューが重要だ。集中は後継者と処理能力のリスクを作る。

プロジェクト資料によれば Network Time Foundation は支援を提供し、PTP/SyncE Consortium を運営する。ただし、その関係だけで全コード判断の所有権や公表済み linuxptp 予算が確立するわけではない。資金、レビュー権限、支援上の約束は区別すべきだ。

これは管理上の細部ではない。高精度時刻システムには信頼できるソフトウェア源が必要であり、明確なリリース来歴は基準識別や経路遅延と同じく、時計を信頼するための証拠連鎖の一部である。

オープンソフトウェアはライセンス依存を減らす一方、時刻同期の実費を見えるようにする

linuxptp には単独の売上、給与総額、評価額、顧客名簿の公表値がない。GPLv2 コードはノード単位のライセンスなしで利用・変更できる。Network Time Foundation と関連ベンダーは支援を提供し、運用者とハードウェア企業がコードと試験へ貢献する。

ソフトウェアライセンスがなくても高精度時刻は安価とは限らない。運用者は対応 NIC、スイッチ、グランドマスター、GNSS 受信機、アンテナ、発振器、配線、計測器、技術者へ投資し、プロファイルを試験して物理基準経路を保守する。商業価値はこの生態系全体へ分散している。

オープンソフトウェアは交渉力を高め得る。標準 PHC とタイムスタンプインターフェースを公開するハードウェアは、他機器と同じデーモンで動作できる。運用者はサーボとプロトコル挙動を確認し、供給元を変更しても設定を保持できる。

ハードウェアの差別化は大きい。優れたタイムスタンプ装置、発振器、校正を持つ製品には価格上乗せの理由がある。独自ソフトウェアは機能を緊密に統合し、認証や支援を伴える。オープンなデーモンは、安価なカードが同じ誤差予算を満たすことを保証しない。

費用は統合へ移る。商用機器ベンダーは支援契約付きの認定済み一式を提供できる。分離構成は部品選択の自由を与えるが、組み合わせの検証を運用者へ求める。経済性は規模、技能、障害時の影響で変わる。

時刻同期は隠れたアプリケーション費用も生む。明確な用途がないまま PTP を導入すると、事業上の利益なしに機器、攻撃面、運用複雑性が増える。構成を選ぶ前に、誤差予算、ホールドオーバー時間、違反時の影響を定めるべきだ。

要件が実在する場合、オープンな制御は戦略的価値を持つ。通信・産業運用者は重要な時刻サービスを一つの機器ソフトウェアへ縛らずに済み、データセンターは時刻品質を運用自動化やアプリケーション判断へ統合できる。それでもソフトウェアは資本設備の一部にすぎない。

linuxptp の経済的貢献は、市販ハードウェアが無償でグランドマスターになるという主張ではない。選択したハードウェアと基準源を連携させる、共通で検査可能な制御層を提供することにある。

セキュリティの焦点は時計を動かし続けることから、その時刻が正しいと証明することへ移る

従来の監視では時刻を到達可能か停止中かで捉えがちだ。しかし高精度時刻システムは、利用可能なまま誤るという、より危険な故障を起こす。偽装されたグランドマスターや GNSS 信号は、クロックを滑らかに正しい時刻から遠ざけ得る。

PTP ネットワークは、偽造 Announce メッセージ、遅延操作、管理アクセス、侵害された機器を通じて攻撃され得る。悪意あるクロックは魅力的な優先度と品質を通知できる。ネットワーク分離とプロファイル制御は露出を減らすが、物理的な真実を認証しない。

GNSS は妨害と偽装に弱い。妨害は監視していれば明白な喪失となるが、偽装は時刻が徐々にずれるもっともらしい信号を作れる。影響が大きい環境では、複数基準の比較と異常検知が不可欠だ。

遅延攻撃は、経路測定が通常の転送を反映するという仮定を利用する。攻撃者または混雑機器が非対称遅延を加えるとオフセットが偏る。メッセージを暗号で認証しても、遅延の対称性は証明できない。

管理インターフェースにはアクセス制御が必要だ。正規のpmc書き込みや直接 PHC 調整でも挙動を変えられる。ログには基準、優先度、手動操作の変更を残し、遠隔管理を時刻データ経路から分離すべきだ。

基準の多様性には障害領域も含めるべきだ。一つのアンテナを使う二つの GNSS 受信機は同じケーブルと空の事象に弱い。同じ上流基準へ従う二つの PTP グランドマスターも独立した真実を提供しない。地上、原子、拠点間の基準は検証を改善できる。

アプリケーションにはタイムスタンプだけでなく品質と不確かさを渡すべきだ。データベースは不確かさが重なるイベントの順序付けを拒否でき、無線システムはホールドオーバーへ入り、セキュリティシステムはクロック基準変更を示せる。デーモン状態を利用側へ届ける必要がある。

linuxptp はこの構成に必要な制御と証拠の多くを提供するが、完全なセキュリティ認証制度ではない。運用者は基準認証、異常検知、対応を周囲へ構築しなければならない。戦略的変化は明確で、目標は同期だけでなく、選択した時刻が正しい時刻であり続けるという監査可能な確信である。

精度は最良の部品ではなく最も弱い境界で決まる

正確なグランドマスターがあっても、NIC がソフトウェアでタイムスタンプを付ければアプリケーション時刻は悪化する。高品質 NIC があっても経路非対称で失敗し、PHC の小さなオフセットを達成してもシステムクロックが逆方向に同期していれば誤る。プロファイル試験に合格しても、ホールドオーバーを認定していなければ GNSS 喪失時に失敗する。

この最弱境界の原則が linuxptp 運用の中心である。すべての主張は基準からアプリケーションまでの完全な経路を示すべきだ。ptp4lのベンチマークはケーブル校正を証明せず、ハードウェア仕様はプロファイル設定を証明せず、安定したオフセットは基準の完全性を証明しない。

責任が見えるためプロジェクト構造は役立つ。カーネルは PHC とタイムスタンプを公開し、ptp4lはネットワーククロックを動かす。phc2sysはクロック間を接続し、ts2phcは外部イベントを扱い、pmcは管理状態を公開する。運用者は補正地点を検査できる。

可視性には統合も必要だ。デーモン、GNSS 受信機、発振器、アプリケーションの指標で識別子と時刻文脈を共有すべきである。障害記録には、選択基準、オフセットの変化、ホールドオーバー開始時刻、予算内に残ったクロックを示すべきだ。

校正は寿命を持つデータとして扱う必要がある。ケーブル変更、ファームウェア更新、ハードウェア交換で補正値は無効になり得る。値を機器へ関連付け、保守後に検証すべきだ。

プロファイル適合は実際の製品間で試験すべきだ。双方の文書が G.8275.1 対応でも、既定値やファームウェアが異なる場合がある。相互運用試験や独立認証機関は不確かさを減らせるが、本番トポロジーは固有である。

リリースとメンテナー体制も一つの境界だ。時刻同期に重要な変更にはレビュー、再現可能なビルド、信頼できる更新経路が必要である。オープンソースはそれを可能にするが、組織が実施済みとは限らない。

linuxptp は高精度時刻制御を標準的な Linux インフラとして利用可能にした。成功はホストがptp4lを実行できるかではなく、通常時と障害時に連鎖全体が誤差予算を説明、監視、防御できるかで測るべきだ。

ナノ秒のタイムスタンプが実配線を表すか実験室だけを表すかは校正で決まる

ハードウェアタイムスタンプはソフトウェア方式より精密でも、遅延を含む。信号はアンテナケーブル、受信機、発振器、基板配線、PHY、MAC を通ってからソフトウェアがクロックを読む。送受信経路には異なる固定オフセットがあり、温度、ファームウェア、機器改版で変わる。したがって高精度時刻にはプロトコル収束だけでなく校正が必要だ。

導入試験は物理基準から始めるべきだ。GNSS アンテナ設備にはケーブル長、接続部、増幅器、受信条件がある。受信機が有効な測位を示しても、ケーブル損傷や誤った遅延補正で時刻がずれる。複数衛星群対応は可用性を高め、異常検知にも役立つが、アンテナ経路が侵害されていないことは証明しない。

PHC 経路にも同様の注意が必要だ。NIC または時刻同期カードは Linux PTP Hardware Clock インターフェースを通じてカウンターを公開する。タイムスタンプ位置は MAC、PHY、別の機器境界の場合があり、ドライバーとファームウェアがイベントの伝達方法を決める。そのため同じくハードウェアタイムスタンプ対応でも、不確かさと非対称性は異なり得る。

校正では、文書化した条件下でシステムを追跡可能な基準と比較する。固定オフセット、温度範囲、ファームウェア、ドライバー、ケーブル構成を記録し、結果をその組み合わせへ結び付ける。NIC 交換、アンテナケーブル移動、ファームウェア更新で無効になり得るため、校正を機種番号の恒久特性とみなしてはならない。

経路非対称性は、通常の遅延測定がそれをクロックオフセットと解釈し得るため、最も難しい誤差の一つである。Sync メッセージと遅延要求の往復時間が異なれば、対称経路の仮定に基づく計算は偏る。サーボは安定しながら正確に誤る。混雑、異なる光ファイバー長、保護切り替え、経路変更により導入後にも非対称性が生じる。

運用者は経路と負荷を意図的に変える試験を必要とする。境界・透過クロックは構成を改善できるが、滞留時間補正とポート動作も検証が必要だ。予備経路は必要になる前に測定すべきである。パケット到達性を保つ冗長経路でも、長さや対称性が劣れば時刻誤差予算に違反する。

最良の証拠は独立比較から得られる。第二の基準、可搬型時計、校正済み試験装置、独立したグランドマスター間の照合は、通常の PTP 状態で見えない共通原因の誤差を明らかにできる。クロックを制御する同じサーボの報告オフセットだけを監視するのは循環した保証である。

校正データは資産・変更管理へ入れるべきだ。インターフェースが稼働していても、校正記録がない、または期限切れなら時刻サービスに不適切である。自動化により未認定ポートがグランドマスターや境界クロック経路になることを防げる。処理と設定が物理連鎖より速く移動し得る Kubernetes 環境では特に重要だ。

linuxptp はこの作業に必要な制御と統計を公開するが、アンテナ、発振器、NIC、経路を認証しない。運用者はこれらの境界を越えて証拠を維持することで精度を獲得する。

時刻品質はCLOCK_REALTIMEから推測させず、アプリケーションへ届ける必要がある

ホストが PTP に正常参加していても、アプリケーションがタイムスタンプを信頼できるか判断できない場合がある。ptp4lが PHC を同期し、phc2sysがシステムクロックへ転送しても、一般的な API は数値だけを返し、現在の不確かさ、基準、ホールドオーバー状態を示さない。

イベント時刻が近いと問題になる。二つのサービスのタイムスタンプ差がクロック誤差より小さい場合、数値の並べ替えはインフラが保証できない確定順序を作る。データベース、セキュリティシステム、分散トレースはノイズから因果関係を推測してしまう。

アプリケーション向け時刻サービスは秒とナノ秒以上を示すべきだ。有用な情報にはクロック識別子、同期状態、推定最大誤差、最終基準更新、ホールドオーバー時間、ステップまたは閏秒イベントがある。アプリケーションはタイムスタンプを受理するか、順序判定幅を広げるか、処理を延期するか判断できる。

推定値は正直でなければならない。サーボオフセットだけでは完全な誤差限界にならず、経路非対称性、校正の不確かさ、基準の完全性を含まない場合がある。偽装グランドマスターへ従いながら小さなローカルオフセットを報告することもある。品質はプロトコル状態に基準監視、校正、発振器挙動を組み合わせるべきだ。

時刻尺度も誤差源になる。PTP は一般に国際原子時に関係する尺度で動き、アプリケーションは UTC を期待する。閏秒と現在の UTC オフセットを正しく扱わなければならない。誤った尺度を転送する設定は、同期成功に見える大きく安定した誤差を生むため、phc2sysの方向とオフセット設定は安全上重要である。

クロックのステップ変更は特別に扱うべきだ。大きな初期誤差はステップで直し、通常時は不連続を避けるため周波数を徐々に変えることがある。単調性に依存するアプリケーションにはステップ発生を知らせる必要がある。継続時間には単調クロックを使い、外部照合だけに同期済み実時刻を使う設計もある。

PTP と NTP の混合環境では品質がさらに複雑になる。timemasterはデーモンを調整できるが、制御ループを防ぎ、基準優先度を決めるのは運用者である。ローカル PTP グランドマスターから遠隔 NTP へ切り替わった後も、同じ誤差範囲だと想定すべきではない。

最も強い構成では、時刻を隠れたホスト特性ではなく品質を明示したサービスとして扱う。linuxptp は制御面の多くを提供するが、タイムスタンプを使う判断まで不確かさを保持するには、追加インターフェース、監視、アプリケーション設計が必要だ。

ホールドオーバー試験はソフトウェアだけでなく発振器の特性が現れるまで続けるべきだ

GNSS などの基準が消えるとクロックはホールドオーバーへ入る。発振器は直近の周波数推定に基づいて動き続け、誤差は品質、温度、経年変化、喪失時のサーボ状態に応じて増える。短時間の実験室切断なら、ほぼどのシステムも耐障害性があるように見える。

意味ある試験は、サービスが耐えるべき障害時間だけ続け、導入環境の範囲内で条件を変える。デーモンが安定状態かだけでなく期間中の時刻誤差を記録する。恒温槽付水晶発振器、チップスケール原子時計、通常の発振器では価格、電力、ホールドオーバーが異なり、ソフトウェアで同等にはできない。

ホールドオーバーへの移行と復帰も試験が必要だ。悪い基準が正しいローカルクロックを直ちに引き離してはならない。基準選択と妥当性確認で不自然な跳躍を拒否できる。基準復帰時の強すぎる補正はステップや振動を生むため、サーボは用途要件に合う形で再同期すべきだ。

冗長グランドマスターは一つの障害を減らすが、GNSS、電源、アンテナ、設定を共有して別の障害を作る場合がある。多様性は基準と障害領域の水準で評価すべきで、一つのアンテナ給電を使う同一ラックの二台は、偽装やケーブル障害に対する独立保護にならない。

プロファイル適合はホールドオーバーを証明しない。通信プロファイルはメッセージとトポロジーを制約し、製品要件は発振器と時刻誤差限界を定め得る。ソフトウェア対応、プロファイル相互運用性、時刻同期機器全体の認定を別々の証拠として保持すべきだ。

linuxptp は状態変更を報告し、基準関係を管理できるが、ホールドオーバー結果はシステム全体の特性である。調達・運用受入では、時間を伴う障害曲線、温度条件、基準障害シナリオ、正確なハードウェア構成を求めるべきだ。その証拠なしに「PTP 対応」と言っても継続性についてほとんど分からない。

バージョンの来歴も時刻保証の一部である

公開リリース状況は分散している。SourceForge は2023年12月のバージョン 4.2 を最新ダウンロードとして表示する一方、活動中のソースツリーはバージョン 4.4 を名乗り、2026年まで開発が続いている。記事はリリース成果物と開発状態を区別し、運用者はパッケージ名だけから修正状況を推測すべきではない。

ディストリビューションや機器ベンダーは、上流版番号を明確に変えずに修正をバックポートすることがある。プロファイル用パッチやドライバー依存関係を持つ場合もある。稼働サービスはソース、パッケージ改版、ビルド設定まで追跡できるべきだ。時刻同期はカーネル、ドライバー、ファームウェア、デーモン版の組み合わせに依存するため、ソフトウェア部品表が役立つ。

更新試験にはプロセス起動だけでなくクロック挙動を含めるべきだ。変更により既定のサーボ値、プロファイル解釈、管理メッセージ、複数ドメイン動作が変わり、同じ設定ファイルでも異なる制御応答になり得る。記録した PTP 交換と実機を使う試験で、全体展開前に版を比較できる。

この来歴は自動運用環境で特に重要だ。コンテナイメージはホストカーネルや NIC ファームウェアとは別に更新され得る。すべての新しい部品が相互運用すると想定せず、対応済み組み合わせ一覧が必要である。追跡不能な版から組み立てた精密時計は、監査可能な高精度時刻インフラではない。

プロファイル相互運用性は設定から推測せず、障害時にも実証すべきだ

二つのシステムが同じ PTP プロファイル対応をうたっても、共に信頼できるサービスを提供できない場合がある。プロファイルはメッセージ頻度、転送方式、クロック役割、選択規則を制約するが、実装は任意動作、管理対応、障害処理で異なり得る。製品の適合表明には、意図したトポロジー上の相互運用試験が必要だ。

試験には通常運用と、グランドマスター喪失、代替マスター選択、パケット遅延変動、インターフェース再設定、境界クロック再起動、優先基準復帰などの遷移を含めるべきだ。ポートが「スレーブ」または「マスター」へ戻ったかだけでなく、時刻誤差と収束を測定する。状態機械のラベルが正しくても、クロックがアプリケーション予算を超える場合がある。

通信環境では SyncE とプロファイル固有の品質通知も加わる。周波数と位相の基準は独立して故障し得る。絶対時刻がずれても周波数を保つ機器や、通知品質が現実と一致しない基準を選ぶ機器もある。基準識別子と観測誤差の照合が必要だ。

相互運用証拠にはソフトウェア、ファームウェア、発振器、ハードウェアの改版を明記すべきだ。ベンダー更新が宣伝上の対応表明を変えずにサーボや BMCA 動作を変えることがある。試験を自動受入手順として維持すれば、プロファイルを紙上の約束から運用上の契約へ変えられる。

時刻障害には故障時点のクロック連鎖を示す記録が必要だ

障害後にログが食い違ってから、原因説明に必要な時刻状態を保存していなかったと判明することが多い。有用な記録には、選択グランドマスター、ポート状態、UTC オフセット、サーボモード、推定オフセットと周波数、基準警告、PHC とシステムクロックの関係、最近のトポロジー変更が含まれる。

記録は検証対象のアプリケーションログから独立して収集すべきだ。ホストクロックのステップで見かけの時系列が変わっても、遠隔収集または単調な連番なら順序を保持できる。管理メッセージと linuxptp ログは状態を提供するが、保存と対応付けは事前に設定する必要がある。

障害後の分析ではタイムスタンプ誤差とイベント処理遅延を区別すべきだ。サービスが正しいタイムスタンプを遅れて出す場合と、誤ったクロックで直ちに記録する場合では対策が異なる。クロック連鎖の証拠がなければ、実際の遅延問題を残したまま「時刻を修正」しかねない。

時刻状態を障害証拠として扱うことはセキュリティ対応にも役立つ。想定外のグランドマスター変更、GNSS 警告、オフセット変化は偽装や設定ミスの調査を支え得る。単一信号から意図を証明するのではなく、タイムスタンプが主張した誤差限界内だったか説明できる文脈を残すことが目的だ。

Linux は各層を選択可能にすることで高精度クロックになった

このプロジェクトが IEEE 1588、ハードウェアタイムスタンプ、SyncE、GNSS、PTP Hardware Clock を発明したわけではない。貢献は、それらを Linux インターフェースで結び、運用者へ制御を公開するユーザー空間システムにある。

この結合は調達と構成を変える。通信ベンダーは標準 Linux を基盤にノードを作り、産業システムは対応 NIC と選択したグランドマスターを組み合わせられる。Kubernetes の Operator は時刻に敏感な処理を認定ホストへ配置し、データセンターチームはクロック品質をアプリケーションへ公開できる。

柔軟性には設計を明示する責任が伴う。どのプロファイル、遅延方式、グランドマスター、ホールドオーバー要件を使うのか。アプリケーションはどのクロックを読み、UTC オフセットをどう管理し、どの基準が独立しているのか。専用機器は一部の判断を隠せるが、オープン構成では避けられない。

公開リリースの曖昧さも、プロジェクト活動と運用上の確実性の違いを示す。保守中のコードでも配布経路は分散し得る。運用者は最も目立つミラーを正式と仮定せず、ソースを確認しなければならない。

メンテナー集中は戦略的懸念である。Richard Cochran の長期的な指導はプロジェクト継続性の大きな要素だ。レビューとリリース知識が分散し、資金関係が明確になれば、生態系はさらに強くなる。

より多くの分散アプリケーションがイベント順序やアクセラレーター連携を重視するにつれ、高精度時刻は広がる可能性が高い。ただし、すべてのデータセンターに通信級 PTP が必要という意味ではない。導入は要件から決めるべきで、アプリケーション誤差予算のないシステムは、健全性を誰も解釈できない高価なインフラになり得る。

linuxptp の持続的価値は、時刻制御ループを検査可能かつ組み合わせ可能にすることだ。Linux にハードウェアタイムスタンプからアプリケーションクロックまでの経路を与える。結果が信頼できるのは、運用者が発振器、経路、プロファイル、基準、監視を同じシステムの一部として扱う場合だけである。