PTM 與時間同步的角色、交換與精度

先找時間來源，再沿每條 Link 配對交換回合

本地時鐘不同，先建立什麼關係？

沿用 Chapter 1 的 Port 與相鄰 Link 概念：Root Port → Switch → Endpoint 是兩條 Link。Switch 從上游取得共同時間，再透過內部機制提供給下游 Port；Endpoint 的 PTM 訊息不會穿過 Switch，一路直接找 Root Port。這正是 Figure 6-23 要說明的分工。

【模擬資料】以下資料為教學用途建立，不代表特定硬體或平台。本章選 Root Port 為 PTM Root。Switch 與 Endpoint 的基本傳輸已就緒，均支援 ePTM（Enhanced Precision Time Management，增強式精確時間管理）；分析的 Endpoint 只有 Function 0。數值案例在 Non-Flit Mode 下進行，兩回合間沒有 Replay、Duplicate、Reset 或 Context 失效事件。Switch 已取得有效共同時間。

為了先看懂 Equation 6-2，案例把所有時間都換成 ns，假設兩邊時鐘速率在這段短時間內相同、沒有漂移，往返的單向傳輸延遲也相同。這些是算例假設；後面再說明不對稱與 Replay 如何影響結果。

想查 Endpoint 能否參與，從哪個結構開始？

先沿 Extended Capability 鏈找 ID=001Fh、Version=1。Figure 7-310 PTM Capability Structure 給出布局：若結構起點為 P，Capability 在 P+04h，Control 在 P+08h。接著用 Figure 7-312／Table 7-275 解碼角色，先不要把結構存在當成已經啟用。

Root Port 提供時間並回覆；Switch 同時要求與回覆。雖然 Switch 的 PTM Root Capable=1，本章仍將 Root Select 清為零，使用上游 Root Port 的時間。Endpoint 只有 Requester 角色；它的 Local Clock Granularity 欄位因 Root Capable=0 而為 RsvdP，不能將其中的零解釋成「Endpoint 沒有本地時鐘」。

對 Switch，§7.9.15 規定一份 Capability 控制整顆 Switch。Switch Downstream Port 不得各自實作這個 Capability；上游是多 Function 時，控制 Function 也不一定就是 Switch Upstream Port Function。應先找出真正的控制結構，再將它的設定對到下游行為。

Base 6.0 §7.9.15 Precision Time Management Extended Capability (PTM Capability)，pp.1260–1264；Figures 7-310–7-312、Tables 7-274／7-275。

找到能力後，怎麼選時間來源與啟用？

開 Figure 7-313／Table 7-276，分開看 PTM Enable [0]、Root Select [1] 與 Effective Granularity [15:8]。本章 Root Port 的 Control=00000003h，表示已啟用且選為 Root；Switch 的 PTM Enable=1、Root Select=0，向上取得共同時間並在下游回覆。

同一條 Link 必須先啟用 Downstream Port 所屬的 PTM 控制，才能啟用 Upstream Port 所屬的控制。因此案例先設定 Root Port，再啟用 Switch，最後啟用 Endpoint。Switch 的一次 Enable 同時控制其 PTM 下游回覆行為，不能在每個下游 Port 尋找不存在的獨立 PTM Control。

Endpoint 的 Effective Granularity 必須採 PTM Root 與所有中間 Time Sources 回報的最大 Local Clock Granularity。本章為 max(4 ns, 8 ns)=8 ns，因此 Endpoint 的 Control=00000801h：Enable=1、Root Select=0、Effective Granularity=08h。這是預期精度資訊，欄位本身不調整時鐘，也不是讀到 8 ns 就代表所有誤差都小於 8 ns。

還要辨認特殊編碼：Local Clock Granularity=00h 表示 Time Source 不實作本地時鐘、只轉傳上游時間；FFh 表示大於 254 ns。若路徑中有 Switch 回報 00h，Effective Granularity 的 00h 表示未知，不能把它當成普通數值零，略過後再取最大值。

Base 6.0 §6.21.3，p.800；§7.9.15.2／§7.9.15.3，Tables 7-275／7-276，pp.1262–1264。

為什麼第二回合需要保存第一回合的時間？

現在只觀察 Link 2：左邊是 Endpoint 的 Upstream Port，右邊是 Switch 的 Downstream Port。先看 Figure 6-22 Precision Time Measurement Link Protocol，把 t1／t4 放在要求方，t2／t3 放在回覆方；再用單引號辨認第二回合。下圖將規格中的關係換成完整算例：

第一回合開始時，Switch 沒有前次歷史資料，所以回覆 PTM Response。它結束這次 dialog，但不帶時間資料。兩端仍會各自保存本地時間；Endpoint 收到 Response 後，至少等待 1 μs 才能送下一筆 Request。案例實際等待 3,000−1,600=1,400 ns，符合這項條件。

第二回合收到 Request 時，Switch 同時具備前次 t3−t2=200 ns，以及本次接收 Request 的 PTM Master Time t2′=5,200 ns，因此回覆 ResponseD。這兩個欄位分屬不同回合。本次處理時間 t3′−t2′=320 ns，應留給後續回合使用，不能拿來取代這次 ResponseD 的 200 ns。

Base 6.0 §6.21.2，Figure 6-22，pp.797–798；§6.21.3.1，p.801；§6.21.3.2，p.803。

ResponseD 的資料放在哪裡？Propagation Delay 又代表什麼？

先查 Table 2-35 Precision Time Measurement Messages。Request 使用 Msg、Code=52h；Response 使用 Msg、Code=53h；ResponseD 則是 MsgD、Code=53h。因此不能只看 Code=53h 就認定一定帶有時間資料。三者使用 TC0、Routing=100b，在相鄰接收端終止；Requester ID 是本段 Transmitting Port 的 ID。

Non-Flit Mode 的 Request／Response 看 Figure 2-61，ResponseD 看 Figure 2-62。ResponseD 的 64-bit PTM Master Time 放在 Header bytes 8–15，32-bit Propagation Delay 放在 1 DW Data Payload。換成 Flit Mode 時，先完成承載與 TLP 重組，再使用 Figures 2-63／2-64，不能沿用 Non-Flit Mode 的基本 Header 格式。

DW

Double Word，4 bytes的資料單位

TLP

Transaction Layer Packet，交易層封包

欄位名雖然叫 Propagation Delay，§6.21.3.2 規定填的是前一回合從收到 Request 到送出 Response 的間隔，即 t3−t2。本章 Data Byte 0–3 為 00 00 00 C8，依本版 Interpretation A，Byte 0 是最高位元組，所以是 000000C8h＝200 ns。PTM Master Time 欄位則為 0000000000001450h＝5,200 ns。真正的單向 Link 延遲仍要用要求方保存的往返時間推算。

若工具將這四個 Payload bytes 反過來解成 C8000000h，就得到 3,355,443,200 ns，已經大於本例 600 ns 的本地往返時間。此時先檢查 Byte Order、欄位起點、回合配對及雙端設定；不要把負的推算結果當成真實傳輸延遲。本版也定義可選的 PTM Propagation Delay Adaptation Capability，供兩端與舊 Interpretation B 相容；Switch 具備此能力時，各 Port 的 Interpretation B 控制獨立。本例假設雙端均使用 A，未啟用 B。

Base 6.0 §2.2.8.10，Table 2-35、Figures 2-61–2-64，pp.190–192；§6.21.3，pp.800–801；§6.21.3.2，p.803。

拿到 ResponseD 後，如何換算事件時間？

先用第一回合的本地時間求往返間隔，再扣掉同一回合的回覆處理時間，剩下的才是兩個方向合計的傳輸時間。依 Equation 6-2 PTM Master Time，在對稱延遲假設下除以二，從本回合 t2′ 扣回去，就得到本回合 Request 送出的 t1′ 所對應的共同時間。

最後一列另假設 Endpoint 在本地 4,000 ns 記錄了一個事件，且 Context 與時鐘速率關係仍有效。前面已建立本地 3,000 ns 對應共同時間 5,000 ns，因此再加上本地經過的 1,000 ns，得到事件的共同時間 6,000 ns。這是在本章短時間、無漂移假設下的作者推演；實作仍須追蹤時鐘速率差與 Context 更新，不能永久套用固定 2,000 ns 位移。

如果誤拿第二回合的 320 ns 去扣第一回合的 600 ns，單向估計會變成 140 ns，t1′ 的共同時間也會錯算為 5,060 ns。這個 60 ns 的差異來自回合配錯，與四則運算本身無關。只保存最後一筆 ResponseD 而遺失 t1／t4，也會缺少公式所需的資料，不能用零補上。

Base 6.0 §6.21.2，Equation 6-2，p.797；PTM Theory and Operation Implementation Note 與 Figure 6-23 Precision Time Measurement Example，p.799。表中讀值與事件換算均為作者建立。

Replay 已經避免重複交付，PTM 為何還要重建？

一般可靠傳輸避免把同一個邏輯 TLP 重複交付，但 PTM 量的是線上實際傳送與接收的時間。§6.21.3 要求送出 Request 的 t1、收到 Request 的 t2、送出 Response／ResponseD 的 t3，以及收到 Response 的 t4，遇到規定的 Replay／Duplicate 情況仍要更新。不能只從去重後的 Transaction 清單推回這些時間點。

TLP

Transaction Layer Packet，交易層封包

本章已假設 ePTM 支援。若 Endpoint 的 PTM Request 被 Replay，Requester 必須使內部 PTM Context 失效；依 ePTM 規則，在完成兩次連續成功、沒有 Replay 的 dialog 前，不能繼續使用該 Context。若 Responder 重送 Response／ResponseD 或收到重複 Request，也須依 §6.21.3.2 清除相應歷史時間，後續可能先回 Response 來重新建立資料。

Figure 6-24 PTM Requester Operation 把這件事分成 Invalid Context、發起 Request、接收 Response／ResponseD 與 Valid Context。收到 Response 會走至少 1 μs 的等待路徑；收到 ResponseD 才有帶資料的路徑，還須搭配本版文字中的 ePTM 失效條件。無回覆時，Requester 在收到對應訊息、Reset，或滿 100 μs 之前，不得再發新的 Request；這項規則不是一般 Memory Read 的 Completion Timeout。

Responder 收到 Request 後必須嘗試在 10 μs 內送 Response 或 ResponseD。歷史資料不足時必須回 Response；若已有歷史間隔但仍須從別處取得共同時間，且預期取得時間超過 10 μs，也允許先回 Response。不能把 10 μs 改寫成每次必定收到 ResponseD 的保證。

Base 6.0 §§6.21.3–6.21.3.2，Figure 6-24，pp.800–803。Non-Flit Mode 與 ePTM／MUST@FLIT 的規範條件須分開閱讀；本案例明確採已支援 ePTM 的情況。

算出共同時間後，精度還受哪些條件限制？

Equation 6-2 用往返傳輸時間的一半估計單向延遲。若兩方向其實分別為 300 ns 與 100 ns，往返合計仍為 400 ns，公式仍估 200 ns；從回覆方接收時間扣回去時，就會比真正的送出時間多算 100 ns。這說明 Effective Granularity=8 ns 並未涵蓋 Link 不對稱造成的全部誤差。

Figure 6-25 PTM Timestamp Capture Example 提醒擷取點要接近 Physical Layer。Non-Flit Mode 以 Port pins 處 STP Symbol／Token 的第一個 bit 為基準；Flit Mode 以標示內含 PTM Message 的 Flit_Marker Indicator bit 為基準，一個 Flit 最多一個 PTM Message。若實際在內部量測，須考量路徑補償；規格沒有對量測準確性與一致性給出完整界限。Analyzer 的顯示時間也必須先確認其擷取基準。

Retimer（重定時器）可能引入方向不對稱與變動，須查廠商資料。不是 Root、且使用本地 Context 回覆的 Switch，最晚須在上一次上游 dialog 後 10 ms 內使 Context 失效，之後必須先刷新才能再回 ResponseD；若實作保證本地時鐘與共同時間 phase locked，週期刷新要求可省略。這項 10 ms 條件不是所有 Endpoint Context 通用的固定有效期限。

透過 PTM 觀察到的共同時間必須單調且嚴格遞增。分析事件時仍須保留時間域與有效期間：同一 PTM Hierarchy 共用一個來源，不同 Hierarchy 的 Master Time 可能獨立；它也不自動等於 UTC 或作業系統的牆上時間。PTM context 如何讓軟體讀取、Switch 內部如何傳時間，以及觸發下一次量測的方法，都有實作決定的部分。讀到 Enable=1，只能先確認允許依角色參與，還需要交換紀錄與 Context 有效性的資料。

Base 6.0 §6.21.1，p.796；§6.21.2 與 Implementation Notes，pp.798–799；§6.21.3，p.800；§6.21.3.3，p.804；Figure 6-25，p.805。

下次拿到一份 PTM Trace，怎麼接回規格？

先畫出時間階層，定位真正的控制 Function、選定 Root 與相鄰 Port。再確認目前模式和訊息種類，依 Table 2-35 配對 Request 與 Response／ResponseD。接著按 Figure 6-22 標記每個回合，核對歷史處理間隔的 byte order、保留的本地時間，以及兩回合之間有沒有 Context 失效事件。資料配齊後才代 Equation 6-2，最後把粒度、擷取點與不對稱誤差附在結果旁。

如果只有一張 Control 快照，還無法做時間換算；如果只有一筆 ResponseD，還缺前次本地往返時間；如果時鐘關係已改變，舊 Context 就不適合拿來換算新的事件。每一步都對應一份具體資料，無須先猜是哪個元件故障。

版本與來源

本章以 PCI Express Base Specification Revision 6.0（6.0-1.0-PUB）為準，文件印刷頁與 PDF 檢視器頁碼相同。拓撲、讀值、時序與計算均為作者建立；未執行實機設定或時間精度量測。本章沒有以外部網站作技術依據。