t the rate for the Sync messages). Even with only 64 packets per second, some of those arrive later than expected with data that was overly delayed and must be discarded. That is because excessive (and variable) delay in the PTP messages has allowed timestamps to become stale by aging more than other packets. To mitigate this, the packet selection mechanism will attempt to discard any "bad" data and concentrate on the "lucky" ones that were only minimally held up. See the section "Packet Delay Variation" later in the chapter to explore the reasons why PDV happens. The question is then, what does the slave clock do with those lucky packets? Figure 9-14 illustrates a functional model for a slave clock recovering frequency from a packet timing signal. This model is loosely based on ITU-T G.8263 but is a common method of implementation. Phase offset Local frequency detector Packet Low-pass Packet timing un Oscillator Output selection filter clock Local time scale Figure 9-14 Architecture of a Packet-Based Frequency Slave Clock The packet timing signal is first processed by a packet selection algorithm that selects the packets used to recover the clock. The time information from the selected packets is used as an input to the phase/time offset detector to compare the reference and local times. The difference between the two times is used to control the rate of the local oscillator that is driving the local time scale. The result is that the local time scale is adjusted to advance at close to the same rate as the master time scale. Normally, this local reference is sourced from a (local) stable oscillator. The performance of the oscillator implemented in the slave equipment is the key factor that determ- lines the frequency accuracy that the slave clock can achieve. From a packet point of view, the main impediment to recovering an accurate frequency is PDV. Therefore, the characteristics of the oscil- lator chosen in the clock design depends on the requirements of the recovered frequency, and on the level of PDV genera