PTP（IEEE 1588）：ナノ秒精度の時刻同期

PTP は何を解決するのか

時刻同期の定番である NTP は、広域でも数ミリ秒、LAN 内でも数百マイクロ秒どまりが現実的な精度です。多くの用途には十分ですが、金融取引の注文タイムスタンプ、5G 基地局の無線フレーム整合、産業オートメーション、分散データベースの順序付けなどは、マイクロ秒〜ナノ秒の同期を要求します。この桁に踏み込むのが PTP（Precision Time Protocol, IEEE 1588）です。

両者の差は精度目標だけではありません。NTP はソフトウェアが受信時に時刻を読むため、OS のスケジューリング遅延や割り込み処理のゆらぎ（ジッタ）がそのまま誤差になります。PTP は「いつパケットがケーブルに出た/入ったか」をできるだけ物理層に近い場所で測り、経路上の機器にもその測定へ参加させることで、ソフト処理のゆらぎを設計的に排除します。

往復測定でオフセットと遅延を分離する

スレーブが知りたいのは自分の時計とマスタの時計の差（オフセット）です。しかしマスタの時刻を載せたメッセージは、ネットワークを伝わる片道遅延 d のぶん遅れて届くので、受信時刻をそのまま比べると「オフセット＋遅延」が混ざってしまいます。PTP はこれを 4 つのメッセージで分離します。

スレーブは 4 つの時刻 {t1,t2,t3,t4} を集めます。マスタ→スレーブの片道遅延は t2 - t1、スレーブ→マスタの片道遅延は t4 - t3 ですが、どちらにもオフセット o が混入しています。t2 - t1 = d + o、t4 - t3 = d - o と書けるので、二式を足し引きすれば d と o が分離できます。

# 往復が対称（両方向の片道遅延が等しく d）と仮定
t2 - t1 = d + o      # マスタ→スレーブ：遅延に +o が乗る
t4 - t3 = d - o      # スレーブ→マスタ：遅延に -o が乗る

# 足すと o が消えて片道遅延が出る
meanPathDelay = ((t2 - t1) + (t4 - t3)) / 2

# 引くと d が消えてオフセットが出る
offset        = ((t2 - t1) - (t4 - t3)) / 2

# スレーブは自分の時計から offset を引いて GM に合わせる

要は RTT を 2 で割って片道遅延を推定し、それを使ってオフセットから遅延ぶんを取り除く、という考え方です。NTP も同じ往復測定の骨格を持ちますが、PTP はこの t1〜t4 を後述のハードウェアで桁違いに正確に取る点が違います。

経路非対称という消えない誤差

上の式が成り立つ前提は、往復で経路遅延が対称（行きと帰りの d が等しい）ことです。現実にはこれが崩れます。行きと帰りで物理経路が違う、片方向だけ別の光ファイバ長を通る、機器内のキューイング遅延が方向で偏る——いずれも非対称を生みます。

非対称が a（行きが帰りより a だけ遅い）あると、推定オフセットには a/2 の誤差がそのまま残ります。しかも厄介なことに、PTP は t1〜t4 の差からしか情報を得ないため、この非対称を自分では検出できません。往復の平均は正しく出るのに、オフセットだけが静かにずれます。

境界クロックと透過クロック

最大の誤差源は、経路上のスイッチ/ルータでの滞留時間のゆらぎです（イーサネットスイッチングの原理 参照）。Sync がスイッチのキューで混雑により毎回違う時間だけ待たされると、片道遅延 d が一定という前提が崩れます。PTP はこれを、中継機器を 2 種類の役割で同期に参加させて解きます。

境界クロック（BC） は、自分が上流から正確に同期し、その時刻を下流へ再配信します。長い経路を 1 ホップずつ区切るので、各区間の誤差が累積しにくくなります。透過クロック（TC） は時刻を再配信せず、PTP メッセージが自機内に滞在した時間を測って、メッセージ内の correctionField にその値を足し込みます。スレーブは最終的に correctionField の合計を遅延計算から差し引くので、各スイッチのキューイングのゆらぎが帳消しになります。

# 透過クロックの滞留時間補正（要点）
on ingress(pkt):
    t_in = hw_timestamp()          # 入口でハードウェア計測
on egress(pkt):
    t_out = hw_timestamp()         # 出口でハードウェア計測
    residence = t_out - t_in       # 自機内の実滞留時間
    pkt.correctionField += residence
    # スレーブ側で d 計算からこの合計を差し引く
    #   → キューイング遅延のゆらぎが相殺される

ハードウェアタイムスタンプが効く理由

PTP の精度を最終的に決めるのは、t1〜t4 をどこで読むかです。OS のソケット層で時刻を読むと、ドライバ・割り込み・スケジューラを通る間にマイクロ秒級のゆらぎが乗ります。これを避けるため、対応 NIC は MAC/PHY 直前で「パケットが実際に媒体へ出入りした瞬間」をハードウェアでタイムスタンプします（RDMA と RoCE と同じく、ソフト経路を迂回して精度を稼ぐ発想です）。

ソフトウェアタイムスタンプが数 µs〜数十 µs のゆらぎを持つのに対し、ハードウェアタイムスタンプは数 ns〜数十 ns に収まります。BC/TC もこの NIC 機能を前提に滞留時間を実測するため、経路上の全機器が PTP ハードウェア対応であることがナノ秒到達の事実上の条件になります。一台でも非対応スイッチが混ざると、そこでゆらぎが入りボトルネックになります。

実務上の含意

PTP を導入する勘所は精度数値そのものより、「経路全体を PTP 対応にできるか」です。GM の品質（GPS/GNSS 同期か）、全ホップが BC か TC か、両端と中継の NIC がハードウェアタイムスタンプ対応か——どれか一つでも欠ければ、その箇所のゆらぎや非対称が支配項になります。データセンタや基地局網のように同一管理ドメインで全機器を揃えられる環境でこそ、PTP は真価を発揮します。

逆に、経路を完全に制御できない一般的な IP 網では NTP（ハードウェアタイムスタンプ対応の実装などで精度を底上げした構成を含む）で十分なことも多く、過剰な投資を避ける判断も重要です。キューイング遅延が同期精度に直結するという意味で、PTP は時刻同期でありながら帯域・レイテンシ・スループットの理解と地続きの技術だと捉えると、設計判断がしやすくなります。