se start of the evening TV news) and then do the same thing one day later. By seeing how much the watch had gained or lost, one could ascertain how fast/slow the oscil- lator was going. Obviously, doing frequency synchronization by this method is somewhat slow, since the slave must compare time with a reference clock over an extended period to detect small gains and losses in the local clock. This means that PTP can be somewhat slow to recover frequency and accurately track it (alignment between a slave and master might take 30-40 mins in some profiles). Because the slave only needs the timestamps from the master, only the Sync messages (and optional Follow_Up for two-step clocks) need to pass in the master->slave direction and, therefore, PTP fre- quency-only synchronization becomes a one-way protocol. The IEEE 1588-2008 recommendation covers this feature in Chapter 12, where it discusses frequency-only synchronization (meaning syn- tonization) versus synchronization. For real-world deployments, there are better ways, such as using a physical signal as a frequency reference, which allows almost instantaneous frequency alignment. This approach commonly uses synchronous Ethernet (SyncE), although it is possible to use a frequency signal from a dedicated timing node (SSU/BITS) or from a GNSS source (for example, a 10 MHz signal). See "Chapter 6. Physical Frequency Synchronization", for more details on this topic. Simultaneously using SyncE to synchronize frequency and PTP to synchronize phase and time is the best of both worlds, and the case of PTP clocks using both methods together is known as hybrid mode. 7.3.1 Timestamps and Timescales "Chapter 1. Introduction to Synchronization and Timing" introduced the internationally accepted systems of time, namely Temps Atomique International (TAI) and Coordinated Universal Time (UTC). The topic now is to examine how PTP uses these forms of time to implement its timestamp- ing mechanisms. The PTP timescale uses an epoch of 1 January 1970 00:00:00 TAI, which means that PTP 