9-16 illustrates what an ideal PDV profile might look like when the packet delay is plotted over time. It is obvious that there are many packets in this example that are close to the floor delay and therefore contain good data (fresh timestamps) to help the clock recover the frequency. There are also quite a few packets that have been seriously delayed, SO the distribution is quite skewed. There are examples of PDV histogram charts in Figure I.2 of G.8260. Figure 9-16 Packet Delay Variation with Clearly Defined Floor Delay In summary, the major impact on performance for packet-based frequency is PDV and the only way that it can be mitigated is to remove/reduce it and to improve the oscillators in the slave clocks. Normally, using a PTP boundary clock between the master and the slave could reset the PDV, but the G.8265.1 telecom profile for frequency synchronization expressly forbids it. Although this problem is tough enough, unfortunately the situation for the phase/time case is even more difficult and complex, and the extra dimension of asymmetry is added. 9.2.1 Packet-Based Phase Distribution Performance Although the metrics might change, most of the lessons from the frequency situation also apply to the case for phase/time: PDV is still an issue, although the impact depends somewhat on how it is being deployed. Thankfully, there are techniques to help mitigate the PDV for the phase/time case that are not available when using the G.8265.1 profile. But the major additional headache for phase/time is asymmetry, a topic first covered in Chapter 7. To refresh your memory, PTP on the slave needs to know how long a Sync message took to travel from the master, SO that it can adjust for the propagation time when comparing the master's timestamp to its own clock. PTP determines that master-to-slave transfer time by assuming it is ex- actly half of the round-trip time. Anything that invalidates this assumption introduces an error in the calculation of correct time and results in a phase offset (error) on the slave. This 