From <IEEE-1588 2008> clause 11
Computation of clock offset in ordinary and boundary clocks
简单地说，在ordinary或boundary clock中计算master与slave之间的timeOffset可以用以下式子：
<offsetFromMaster> = <Time on the slave clock> ─ <Time on the master clock>
<offsetFromMaster>的计算流程：
- slave收到Sync message时，生成<syncEventIngressTimestamp>（考虑measurementLatency和delayAsymmetry）
- 对于one-step，则 <offsetFromMaster> =
<syncEventIngressTimestamp> ─ <originTimestamp> ─ <meanPathDelay> ─ correctionField of Sync message - 对于two-step，则 <offsetFromMaster> =
<syncEventIngressTimestamp> ─ <preciseOriginTimestamp> ─ <meanPathDelay> ─ correctionField of Sync message ─ correctionField of Follow_Up message.
- <originTimestamp>即Sync message中originTimestamp field的值。
- <preciseOriginTimestamp>即Follow_Up message中preciseOriginTimestamp field的值。
- <meanPathDelay>的计算，取决于port使用delay request-response mechanism还是peer delay mechanism。
Delay request-response mechanism
delay request-response mechanism计算一对PTP port之间的<meanPathDelay>。
Delay request-response path length measurement
Delay request-response mechanism operational specifications
delay request-response measurement中的<meanPathDelay>应按照如下步骤来计算：
- 根据9.5.9的规则，触发master node发送Sync message。
若为two-step clock，则根据9.5.9.4发送Follow_Up。 - slave node在收到Sync message时，记录
。（在Sync中考虑加入asymmetry correction）
根据9.5.11.2中对Delay_Req的timing requirement，将Delay_Req发送出去，生成。（在其中考虑加入asymmetry correction）
- Master node收到Delay_Req时，生成
，准备Delay_Resp message，将Delay_Req中的correctionField加到Delay_Resp中。
将 - Slave收到Delay_Resp时，
若为one-step，则<meanPathDelay> =
[ (t2 - originTimestamp of Sync - correctionField of Sync) + (receiveTimestamp of Delay_Resp - t3 - correctionField of Delay_Resp) ]/2
=
[ (t2 - t3) + (receiveTimestamp of Delay_Resp – originTimestamp of Sync) – correctionField of Sync – correctionField of Delay_Resp]/2
（因为Sync和Delay_Resp的方向都是从Master->Slave，所以它们的delayAsymmetry都是减去的）
若为two-step，计算方法基本与上面一样。只要将originTimestamp of Sync改成preciseOriginTimestamp of Follow_Up，然后再多减去一个Follow_Up的correctionField。
一般来说，在delay request-response path length measurement中，会使用在Delay_Req message之前发送的最近的Sync和对应Follow-up message中的timestamp和correctionField。但实际上，delay request response measurement会使用任意Sync和对应的Follow-up message，即使这会降低计算出的<meanPathDelay>的accuracy。
Peer delay mechanism
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状态无关。
Peer delay link measurement
message timing
初始的Pdelay_Req message应在被要求发送时发送。
之后的Pdelay_Req message的平均发送间隔(秒)，其以2为底的对数，应不小于requestor clock的data set中的portDS.logMinPdelayReqInterval。
Pdelay_Resp message应该在收到Pdelay_Req后尽快发出。Pdelay_Resp_Follow_Up同理。
operation specification
meanPathDelay的测量计算应该按照如下步骤进行：
- delay requestor，Node-A，准备Pdelay_Req message，将correctionField和originTimestamp设为0。将其发出，记录
。
- delay responder，Node-B，收到Pdelay_Req时记录
放入Pdelay_Resp的correctionField中。
（如果Node-B为two-step clock，则基本步骤不变，但是把correctionField放到Pdelay_Resp_Follow_Up中） - Node-A收到Pdelay_Resp时生成
<meanPathDelay> = [correctionField ] / 2
其实在协议11.4.3中，还介绍了其他的实现，比如在当responder为two-step clock时，将
不过这里只介绍简单的方式，意在理解计算meanPathDelay的思路。
Restriction
delay Requestor，发送一条Pdelay_Req，可能会收到0，1，或多条Pdelay_Resp message。
我们可以通过sourcePortIdentity来判断是否收到了来自不同设备的多条Pdelay_Resp。
这种情况在当Node-A和Node-B之间存在e2e TC或bridge或其他multiport device时有可能发生。虽然我们可以区分这多条消息，但是我们并不能将这些message中包含的信息对应到接收的Sync message中。
遇到上面的情况时，应该采取如下措施：
- 若没有Pdelay_Resp被收到，则继续重传Pdelay_Req。重传的速率以具体实现为准。
- 当1条Pdelay_Resp被收到，按照协议中的流程正常处理。
- 当多条Pdelay_Resp被收到，Node-A应该
1.若为ordinary clock或boundary clock，进入FAULTY状态；若为p2p transparent clock，进入fault condition。继续重传Pdelay_Req，重传的速率以具体实现为准。此时收到的Sync，Follow_Up应全部丢弃。
2.根据实现自行解决。
Path delay correction in transparent clocks
当peer-to-peer transparent clock的port收到Sync message时，应该：
- 若此clock为one-step，将事先计算好的<meanPathDelay>(对应Sync message来的那条path)加到Sync message的correctionField中。
- 若此clock为two-step，将<meanPathDelay>加到Sync message对应的Follow_Up message的correctionField中(应该在residence time correction完成后进行)。
当end-to-end transparent clock的port收到Sync message时，不应该对path delay进行调整。
Residence time correction in transparent clock for events
所谓residence time，就是event message在经过transparent clock时的ingress timestamp和egress timestamp之差。
Residence time correction for Sync messages
对于one-step transparent clock，将<residenceTime>加到Sync message的correctionField。 收到Follow_Up messages则不做任何改变。
对于two-step transparent clock，
- 若收到Sync message，其中twoStepFlag为TRUE，则记下Sync message的egress timestamp，计算<residenceTime>，加到对应的Follow_Up message的correctionField中。
- 若收到Sync message，其中twoStepFlag为FALSE，则将其改为TRUE，尽快将Sync message发出，记下egress timestamp。
生成Follow_Up message，将Sync message的originTimestamp copy到自己的preciseOriginTimestamp中。将<residenceTime>写到correctionField中（如果为peer-to-peer transparent clocks，此行为应在<meanPathDelay>之前完成）
Residence time correction for Delay_Req messages
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中。
Residence time correction for Pdelay_Req and Pdelay_Resp messages
Pdelay_Req and Pdelay_Resp messages被peer-to-peer transparent clocks收到后就达到终点了。所以这里只讨论end-to-end transparent clocks。
一般peer-to-peer clocks只会用在全是peer-to-peer clock的system中。这里之所以支持end-to-end transparent clocks的使用，是为了支持此协议的未来版本对mixed systems中对p2p clocks的one-to-many connections的实现。
这里的具体实现，参考协议11.5.4
网友评论