 Delay_Req and places an estimate of the t3 timestamp in the origin- Timestamp field (it could also just place a zero in there). So, the t3 value is 144:651.1 but the originTimestamp value written into the message is 144:300 (an estimation). The asymmetry correction of -0.20 ns is subtracted from the CF field (making it +0.20 ns) before transmission. 5. The TC receives the Delay_Req message 0.90 ns later (slightly slower in this direction) and adds the measured residence time of 237.5 to the CF. But it is also configured with -0.05 ns asymmetry on the path to the GM, SO it adds that value to the CF as well. Now the CF contains the value of 237.65 (0.20 + 237.5 + -0.05). 6. The GM receives the Delay_Req message 0.55 ns later and generates a timestamp of 144:864.85. One could deduce that timestamp starting with the t3 timestamp on the BC (144:651.1) and then subtracting the clock offset of 25.2 ns (the BC is fast by that much). Then to the remaining 144:625.9, add the TC residence time of 237.5 and the two (real, unadjusted) transit times of 0.90 ns and 0.55 ns. 7. The GM generates the Delay_Resp and places the seconds from the t4 timestamp in the receive- Timestamp field (like originTimestamp, this field also carries no sub-nanoseconds). However, the GM must return the incoming CF value to the slave as well as the sub-nanoseconds of the t4 timestamp. So, it subtracts the sub-nanosecond value of the t4 timestamp from the CF value from the incoming Delay_Req. So, the t4 was 144:864.85 and the GM writes 144:864 into the receive Timestamp field. But the incoming CF value was 237.65 (from the TC), and before copying that to the outgoing CF field, the GM subtracts the sub-nanosecond value of t4, 0.85 ns, from the 237.65, giving 236.8 ns in the CF of the Delay_Resp. 8. Now the slave can calculate the mean path delay and offset from master using the four known timestamps. There is no correction applied to the Delay_Resp because it is not a time-sensitive message. The four timestamps, as they are received on the slave port