From <IEEE-1588 2008> clause 11
簡單地說，在ordinary或boundary clock中計算master與slave之間的timeOffset可以用以下式子：
<offsetFromMaster> = <Time on the slave clock> ─ <Time on the master clock>
<offsetFromMaster>的計算流程：
delay request-response mechanism計算壹對PTP port之間的<meanPathDelay>。
delay request-response measurement中的<meanPathDelay>應按照如下步驟來計算：
The peer delay mechanism measures the port-to-port propagation time, i.e., the link delay, between two communicating ports supporting the peer delay mechanism.
link delay measurement在實行peer delay mechanism的每個port上獨立地運行。
這也意味著，link兩端的port都要各自進行測量。這樣的好處是network reconfiguration時可以快速調整。
在ordinary和boundary clock中，peer delay measurement與port是Master還是Slave狀態無關。
初始的Pdelay_Req message應在被要求發送時發送。
之後的Pdelay_Req message的平均發送間隔(秒)，其以2為底的對數，應不小於requestor clock的data set中的portDS.logMinPdelayReqInterval。
Pdelay_Resp message應該在收到Pdelay_Req後盡快發出。Pdelay_Resp_Follow_Up同理。
meanPathDelay的測量計算應該按照如下步驟進行：
delay Requestor，發送壹條Pdelay_Req，可能會收到0，1，或多條Pdelay_Resp message。
我們可以通過sourcePortIdentity來判斷是否收到了來自不同設備的多條Pdelay_Resp。
遇到上面的情況時，應該采取如下措施：
當peer-to-peer transparent clock的port收到Sync message時，應該：
當end-to-end transparent clock的port收到Sync message時，不應該對path delay進行調整。
所謂residence time，就是event message在經過transparent clock時的ingress timestamp和egress timestamp之差。
對於one-step transparent clock，將<residenceTime>加到Sync message的correctionField。 收到Follow_Up messages則不做任何改變。
對於two-step transparent clock，
Peer-to-peer transparent clocks不支持Delay_Req messages，所以這裏只討論end-to-end transparent clocks。
對於One-step end-to-end transparent clocks，
步驟比較簡單，就是把計算好的<residenceTime>加到correctionField of the Delay_Req message。
若收到Delay_Resp messages，無需任何改動。
對於Two-step end-to-end transparent clocks，
記下Delay_Req message的egressTimestamp，計算出<residenceTime>。
當收到對應的Delay_Resp message並準備將其發出時，將<residenceTime>加到Delay_Resp message的correctionField中。
Pdelay_Req and Pdelay_Resp messages被peer-to-peer transparent clocks收到後就達到終點了。所以這裏只討論end-to-end transparent clocks。
這裏的具體實現，參考協議11.5.4