 on the BC, are as follows: 1. 144:7 with CF of 207.55 ns that is added to the timestamp 2. 144:241.05 3. 144:651.10 4. 144:864 with CF of 236.80 that is subtracted from the timestamp So, from the Chapter 7 section "The (Simple) Mathematics," you see that the calculation for mean path delay is and offset from masteris(t2-t1t3-t42 Mean path delay = [144:241.05 - (144:7 + 207.55) + (144:864 - 236.80) - 144:651.10]/2 This gives 2.6 = 1.3 ns (the example shows that it is (0.65 + 0.5 + 0.9 + 0.55) =1.3 ns). Offset from master = [144:241.05 - (144:7 + 207.55) + 144:651.10 - (144:864 - 236.80)]/2. This gives 50.4/2 = 25.2 ns (although you knew that at the beginning). Despite the asymmetry of the links between the three participating nodes, the asymmetry was cor- rected by being measured, configured, and used by the slave in the determination of both the time values. In this case an asymmetry of +0.5 ns was configured on the TC for its incoming link from the GM, and an asymmetry of -0.20 ns was configured on the BC for its link to the TC. Additionally, the asymmetry in the time spent in the TC was also eliminated by using the CF to re- ceive and carry the residence time to the slave. The Sync message spent 204.7 ns passing through the TC, and the Delay_Req spent 237.5 ns in the other direction. This would have introduced 16.4 ns of phase error on the slave because the slave would have calculated the delay through the inter- vening node to be 221.1 ns (the mean/average of 204.7 and 237.5) rather than the real values. 9.3.1 Packet Delay Variation The topic of PDV when discussing phase/time distribution covers two different scenarios. In the case where there is no physical frequency, the situation is much like the case with frequency-only packet. In some ways, that is what G.8265.1 and G.8275.2 have in common-they are both used to recover frequency with packets. Of course, the major difference is that G.8275.2 supports boundary clocks, SO you have a tool to combat against an accumulation in PDV. Figure 9-21 illustrates how 