Precision Time Protocol
Imagine needing to coordinate events across a vast network with mind-boggling precision — not just seconds, but down to tiny fractions of a microsecond. That's the challenge the Precision Time Protocol, or PTP, was designed to solve. It allows clocks in a computer network to synchronize with an accuracy far beyond what typical network time protocols can achieve, making truly coordinated operations possible. Let's delve into how this intricate dance of time works, enabling everything from high-frequency trading to the seamless symphony of 5G networks. PTP offers sub-microsecond clock synchronization, bridging the gap between less precise protocols like NTP and expensive satellite-based systems like GPS. The protocol uses a hierarchical master-slave architecture with specialized clocks and an algorithm to elect the most accurate 'grandmaster' time source. Synchronization involves a four-message exchange between devices to precisely calculate network delay and clock offset, ensuring highly accurate time alignment.
AI Summary
Imagine needing to coordinate events across a vast network with mind-boggling precision — not just seconds, but down to tiny fractions of a microsecond. That's the challenge the Precision Time Protocol, or PTP, was designed to solve. It allows clocks in a computer network to synchronize with an accuracy far beyond what typical network time protocols can achieve, making truly coordinated operations possible. Let's delve into how this intricate dance of time works, enabling everything from high-frequency trading to the seamless symphony of 5G networks.
- PTP offers sub-microsecond clock synchronization, bridging the gap between less precise protocols like NTP and expensive satellite-based systems like GPS.
- The protocol uses a hierarchical master-slave architecture with specialized clocks and an algorithm to elect the most accurate 'grandmaster' time source.
- Synchronization involves a four-message exchange between devices to precisely calculate network delay and clock offset, ensuring highly accurate time alignment.
The Quest for Perfect Time
In our increasingly connected world, coordinating events isn't just about sharing information; it's about sharing it at the exact same moment. While most computers rely on protocols like NTP for synchronization to the nearest millisecond, some applications demand far greater precision—think thousands of times more accurate.
This is where the Precision Time Protocol, or PTP, steps in. It's a network protocol designed to synchronize clocks across a local area network with astonishing sub-microsecond accuracy. To put that into perspective, a microsecond is one-millionth of a second!
Where Precision Matters Most
Why would such extreme precision be necessary? Industries like finance use PTP to timestamp high-frequency trades, ensuring fair order execution. Telecommunication networks, especially 5G, depend on it to coordinate signals from mobile phone towers. Even sub-sea acoustic arrays and advanced control systems use PTP when satellite signals are unavailable or too costly.
A Protocol with a Purpose
The journey of PTP began in 2002 with the IEEE 1588-2002 standard. Its creation filled a unique void: systems needing more accuracy than the Network Time Protocol (NTP) could provide, but without the expense or limitations of GPS receivers at every node.
Subsequent versions, like PTPv2 (IEEE 1588-2008) and PTPv2.1 (IEEE 1588-2019), brought significant improvements in accuracy, robustness, and flexibility. These updates introduced the concept of 'profiles,' allowing PTP to be tailored for specific applications, from power grids to professional audio-visual setups.
Orchestrating Time: PTP's Architecture
At its heart, PTP uses a hierarchical master-slave architecture. Imagine a conductor (the master) leading an orchestra (the slave clocks), ensuring everyone plays in perfect time. In a PTP network, one clock is designated as the master, and all other clocks synchronize to it.
Clocks in the System
There are a few key types of clocks in a PTP system. An 'ordinary clock' is a basic device with a single network connection, acting either as a source of synchronization (a master) or a destination (a slave). For more complex networks, 'boundary clocks' exist. These devices have multiple network connections, synchronizing one segment of the network to another, effectively passing time down the chain.
The ultimate source of time in any PTP domain is the 'grandmaster clock.' This is the elected leader of the entire synchronization hierarchy, providing the reference time that all other clocks strive to match.
A special innovation in PTPv2 is the 'transparent clock.' Network equipment like switches and routers can introduce delays, impacting synchronization accuracy. Transparent clocks actively measure the time PTP messages spend traversing the device and modify the message timestamps to compensate for these delays, significantly boosting overall accuracy.
The Language of Time: Messages and Epochs
PTP uses a variety of messages to achieve and maintain synchronization. These messages fall into two categories: 'event messages,' which are time-critical because their precise transmission and reception timestamps are essential for accuracy, and 'general messages,' which convey important PTP data but aren't as time-sensitive.
Interestingly, while many computer systems rely on Coordinated Universal Time (UTC) and its leap seconds, PTP bases its core time on International Atomic Time (TAI). The PTP grandmaster, however, communicates the current offset between UTC and TAI, allowing devices to convert PTP time to UTC when needed.
Transporting Time
PTP messages typically travel over User Datagram Protocol (UDP) and Internet Protocol (IP). Event messages, like 'Sync' and 'DelayReq,' which demand the highest timing precision, are sent to specific multicast IP addresses and port 319. General messages, such as 'Announce' and 'FollowUp,' use port 320.
PTP also introduces the concept of 'domains.' A domain is simply a group of clocks that are synchronizing with each other using PTP. This allows multiple, independent time synchronization systems to coexist on the same physical network without interfering with one another.
Electing the Leader: The Best Master Clock Algorithm
With multiple clocks in a network, how does PTP decide which one gets to be the grandmaster? This critical decision is made by the 'Best Master Clock Algorithm,' or BMCA. It's a distributed election process that evaluates several clock properties to determine the highest quality time source.
The BMCA considers a hierarchy of properties, prioritizing them in a specific order: first, the clock's quality level (e.g., GPS-synchronized vs. free-running); then, its priority values; next, its accuracy; and finally, its MAC address as a tie-breaker. The clock with the 'best' combination of these properties wins the election.
Clocks continuously exchange 'Announce' messages, advertising their properties. If a clock determines it's 'better' than the current grandmaster based on the BMCA rules, it will start sending its own Announce messages. Once the current grandmaster recognizes a superior clock, it gracefully steps aside, allowing the new grandmaster to take over.
The Dance of Synchronization: How Clocks Adjust
Once a grandmaster is elected, the real work of synchronization begins. Each slave clock needs to calculate its offset from the grandmaster and the network delay between them to precisely adjust its own internal clock. This is achieved through a carefully choreographed four-message exchange.
Measuring the Offset and Delay
The process starts with the grandmaster sending a 'Sync' message at a precise time, let's call it $T1$. Upon receiving this message, the slave records its own local time of arrival, $T1'$. Some grandmasters, especially those with hardware timestamping, can embed $T1$ directly into the Sync message itself. Others, that can't timestamp the Sync message instantly, send a separate 'FollowUp' message containing $T1$ after the Sync message has been sent.
Next, the slave initiates a 'DelayReq' message at its local time $T2$, sending it to the grandmaster. The grandmaster receives this request and records its own local time of arrival, $T2'$. It then responds with a 'DelayResp' message, which contains the $T2'$ timestamp.
With these four timestamps—$T1$, $T1'$, $T2$, and $T2'$—the slave clock can now calculate both the network path delay ($d$) and its own offset ($o$) relative to the grandmaster. This calculation relies on two key assumptions: that the delay from master to slave is equal to the delay from slave to master, and that the clock offset remains constant during the measurement period.
First, the average one-way network delay ($d$) is calculated. This formula averages the time the Sync message took to travel from master to slave ($T1' - T1$) and the DelayReq message took from slave to master ($T2' - T2$), adjusted for the slave's offset.
d = \frac{(T_{2}' - T_{1}) + (T_{1}' - T_{2})}{2}With the network delay known, the slave can then precisely determine its offset ($o$) from the grandmaster. A positive $o$ means the slave clock is ahead of the master, while a negative $o$ means it's behind. The slave then adjusts its clock by this amount, bringing it into precise alignment with the grandmaster.
o = \frac{(T_{1}' - T_{1}) - (T_{2}' - T_{2})}{2}This entire process is repeated continuously, often many times per second, to ensure that clocks remain synchronized even with minor drifts or network fluctuations. The speed and accuracy of these exchanges are what make PTP a powerhouse for critical timing applications.
Article
Precision Time Protocol
The Precision Time Protocol (PTP) is a protocol for clock synchronization throughout a computer network with relatively high precision as compared to using the earlier developed Network Time Protocol (NTP) and therefore potentially higher accuracy depending on the configuration. In a local area network (LAN), accuracy can be sub-microsecond – making it suitable for measurement and control systems applications. PTP can be used to synchronize financial transactions, mobile phone tower transmissions, sub-sea acoustic arrays, and networks that require precise timing as an alternative to using the timestamp of satellite navigation signals or where sub-nanosecond accuracy as provided by the White Rabbit Project is unnecessary.
The first version of PTP, IEEE 1588-2002, was published in 2002. IEEE 1588-2008, also known as PTP Version 2, is not backward compatible with the 2002 version. IEEE 1588-2019 was published in November 2019 and includes backward-compatible improvements to the 2008 publication. IEEE 1588-2008 includes a profile concept defining PTP operating parameters and options. Several profiles have been defined for applications including telecommunications, electric power distribution and audiovisual uses. IEEE 802.1AS is an adaptation of PTP, called gPTP, for use with Audio Video Bridging (AVB) and Time-Sensitive Networking (TSN).
History
Precision Time Protocol
According to John Eidson, who led the IEEE 1588-2002 standardization effort, "IEEE 1588 is designed to fill a niche not well served by either of the two dominant protocols, NTP and GPS. IEEE 1588 is designed for local systems requiring accuracies beyond those attainable using NTP. It is also designed for applications that cannot bear the cost of a GPS receiver at each node, or for which GPS signals are inaccessible."
PTP was originally defined in the IEEE 1588-2002 standard, officially titled Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems, and published in 2002. In 2008, IEEE 1588-2008 was released as a revised standard; also known as PTP version 2 (PTPv2), it improves accuracy, precision and robustness but is not backward compatible with the original 2002 version. IEEE 1588-2019 was published in November 2019, is informally known as PTPv2.1 and includes backwards-compatible improvements to the 2008 publication.
Architecture
Precision Time Protocol
The IEEE 1588 standards describe a hierarchical master–slave architecture for clock distribution consisting of one or more network segments and one or more clocks. An ordinary clock is a device with a single network connection that is either the source of or the destination for a synchronization reference. A source is called a master (alternately timeTransmitter), and a destination is called a slave (alternately timeReceiver). A boundary clock has multiple network connections and synchronizes one network segment to another. A single, synchronization leader is selected, a.k.a. elected, for each network segment. The root timing reference is called the grandmaster.
A relatively simple PTP architecture consists of ordinary clocks on a single-segment network with no boundary clocks. A grandmaster is elected and all other clocks synchronize to it.
IEEE 1588-2008 introduces a clock associated with network equipment used to convey PTP messages. The transparent clock modifies PTP messages as they pass through the device. Timestamps in the messages are corrected for time spent traversing the network equipment. This scheme improves distribution accuracy by compensating for delivery variability across the network.
PTP typically uses the same epoch as Unix time (start of 1 January 1970). While the Unix time is based on Coordinated Universal Time (UTC) and is subject to leap seconds, PTP is based on International Atomic Time (TAI). The PTP grandmaster communicates the current offset between UTC and TAI, so that UTC can be computed from the received PTP time.
Protocol details
Precision Time Protocol
Synchronization and management of a PTP system is achieved through the exchange of messages across the communications medium. To this end, PTP uses the following message types.
• Sync, FollowUp, DelayReq and DelayResp messages are used by ordinary and boundary clocks and communicate time-related information used to synchronize clocks across the network. • PdelayReq, PdelayResp and PdelayRespFollowUp are used by transparent clocks to measure delays across the communications medium so that they can be compensated for by the system. Transparent clocks and these messages associated with them are not available in the original IEEE 1588-2002 PTPv1 standard, and were added in PTPv2. • Announce messages are used by the best master clock algorithm in IEEE 1588-2008 to build a clock hierarchy and select the grandmaster. • Management messages are used by network management to monitor, configure and maintain a PTP system. • Signaling messages are used for non-time-critical communications between clocks. Signaling messages were introduced in IEEE 1588-2008.
Messages are categorized as event and general messages. Event messages are time-critical in that accuracy in transmission and receipt timestamp accuracy directly affects clock distribution accuracy. Sync, DelayReq, PdelayReq and Pdelayresp are event messages. General messages are more conventional protocol data units in that the data in these messages is of importance to PTP, but their transmission and receipt timestamps are not. Announce, FollowUp, DelayResp, PdelayRespFollowUp, Management and Signaling messages are members of the general message class.
Message transport
PTP messages may use the User Datagram Protocol over Internet Protocol (UDP/IP) for transport. IEEE 1588-2002 uses only IPv4 transports, but this has been extended to include IPv6 in IEEE 1588-2008. In IEEE 1588-2002, all PTP messages are sent using multicast messaging, while IEEE 1588-2008 introduced an option for devices to negotiate unicast transmission on a port-by-port basis. Multicast transmissions use IP multicast addressing, for which multicast group addresses are defined for IPv4 and IPv6 (see table). Time-critical event messages (Sync, Delayreq, PdelayReq and PdelayResp) are sent to port number 319. General messages (Announce, FollowUp, DelayResp, PdelayRespFollowUp, management and signaling) use port number 320.
<table><thead><tr><th>Messages</th><th>IPv4</th><th>IPv6</th><th>IEEE 802.3 Ethernet</th><th>Type</th></tr></thead><tbody><tr><td>All except peer delay messages</td><td>224.0.1.129</td><td>FF0x::181</td><td>01-1B-19-00-00-00</td><td>Forwardable</td></tr><tr><td>Peer delay messages: PdelayReq, PdelayResp and PdelayRespFollowUp</td><td>224.0.0.107</td><td>FF02::6B</td><td>01-80-C2-00-00-0E</td><td>Non-forwardable</td></tr></tbody></table>
In IEEE 1588-2008, encapsulation is also defined for DeviceNet, ControlNet and PROFINET.
Domains
A domain is an interacting set of clocks that synchronize to one another using PTP. Clocks are assigned to a domain by virtue of the contents of the Subdomain name (IEEE 1588-2002) or the domainNumber (IEEE 1588-2008) fields in PTP messages they receive or generate. Domains allow multiple clock distribution systems to share the same communications medium.
<table><thead><tr><th>Subdomain name field contents (IEEE1588-2002)</th><th>IPv4 multicast address (IEEE1588-2002)</th><th>domainNumber (IEEE1588-2008)</th><th>Notes</th></tr></thead><tbody><tr><td>DFLT</td><td>224.0.1.129</td><td>0</td><td>Default domain</td></tr><tr><td>ALT1</td><td>224.0.1.130</td><td>1</td><td>Alternate domain 1</td></tr><tr><td>ALT2</td><td>224.0.1.131</td><td>2</td><td>Alternate domain 2</td></tr><tr><td>ALT3</td><td>224.0.1.132</td><td>3</td><td>Alternate domain 3</td></tr><tr><td>Application specific up to 15 octets</td><td>224.0.1.130, 131 or 132 as per hash function on Subdomain name</td><td>4 through 127</td><td>User-defined domains</td></tr></tbody></table>
Best master clock algorithm
Precision Time Protocol
The best master clock algorithm (BMCA) performs a distributed selection of the best clock to act as leader based on the following clock properties:
• Identifier – A universally unique numeric identifier for the clock. This is typically constructed based on a device's MAC address. • Quality – Both versions of IEEE 1588 attempt to quantify clock quality based on expected timing deviation, technology used to implement the clock or location in a clock stratum schema, although only V1 (IEEE 1588-2002) knows a data field stratum. PTP V2 (IEEE 1588-2008) defines the overall quality of a clock by using the data fields clockAccuracy and clockClass. • Priority – An administratively assigned precedence hint used by the BMCA to help select a grandmaster for the PTP domain. IEEE 1588-2002 used a single Boolean variable to indicate precedence. IEEE 1588-2008 features two 8-bit priority fields. • Variance – A clock's estimate of its stability based on observation of its performance against the PTP reference.
IEEE 1588-2008 uses a hierarchical selection algorithm based on the following properties, in the indicated order:
• Priority 1 – the user can assign a specific static-designed priority to each clock, preemptively defining a priority among them. Smaller numeric values indicate higher priority. • Class – each clock is a member of a given class, each class getting its own priority. • Accuracy – precision between clock and UTC, in nanoseconds (ns) • Variance – variability of the clock • Priority 2 – final-defined priority, defining backup order in case the other criteria were not sufficient. Smaller numeric values indicate higher priority. • Unique identifier – MAC address-based selection is used as a tiebreaker when all other properties are equal.
IEEE 1588-2002 uses a selection algorithm based on similar properties.
Clock properties are advertised in IEEE 1588-2002 Sync messages and in IEEE 1588-2008 Announce messages. The current leader transmits this information at regular interval. A clock that considers itself a better leader will transmit this information in order to invoke a change of leader. Once the current leader recognizes the better clock, the current leader stops transmitting Sync messages and associated clock properties (Announce messages in the case of IEEE 1588-2008) and the better clock takes over as leader. The BMCA only considers the self-declared quality of clocks and does not take network link quality into consideration.
Synchronization
Precision Time Protocol
Via BMCA, PTP selects a source of time for an IEEE 1588 domain and for each network segment in the domain.
Clocks determine the offset between themselves and their leader. Let the variable ${\displaystyle t}$ represent physical time. For a given follower device, the offset ${\displaystyle o(t)}$ at time ${\displaystyle t}$ is defined by:
where ${\displaystyle s(t)}$ represents the time measured by the follower clock at physical time ${\displaystyle t}$, and ${\displaystyle m(t)}$ represents the time measured by the leader clock at physical time ${\displaystyle t}$.
The leader periodically broadcasts the current time as a message to the other clocks. Under IEEE 1588-2002 broadcasts are up to once per second. Under IEEE 1588-2008, up to 10 per second are permitted.
IEEE 1588 synchronization mechanism and delay calculation
Each broadcast begins at time ${\displaystyle T{1}}$ with a Sync message sent by the leader to all the clocks in the domain. A clock receiving this message takes note of the local time ${\displaystyle T{1}'}$ when this message is received.
The leader may subsequently send a multicast FollowUp with accurate ${\displaystyle T{1}}$ timestamp. Not all leaders have the ability to present an accurate timestamp in the Sync message. It is only after the transmission is complete that they are able to retrieve an accurate timestamp for the Sync transmission from their network hardware. Leaders with this limitation use the FollowUp message to convey ${\displaystyle T{1}}$. Leaders with PTP capabilities built into their network hardware are able to present an accurate timestamp in the Sync message and do not need to send FollowUp messages.
In order to accurately synchronize to their leader, clocks must individually determine the network transit time of the Sync messages. The transit time is determined indirectly by measuring round-trip time from each clock to its leader. The clocks initiate an exchange with their leader designed to measure the transit time ${\displaystyle d}$. The exchange begins with a clock sending a DelayReq message at time ${\displaystyle T{2}}$ to the leader. The leader receives and timestamps the DelayReq at time ${\displaystyle T{2}'}$ and responds with a DelayResp message. The leader includes the timestamp ${\displaystyle T{2}'}$ in the DelayResp message.
Through these exchanges a clock learns ${\displaystyle T{1}}$, ${\displaystyle T{1}'}$, ${\displaystyle T{2}}$ and ${\displaystyle T{2}'}$.
If ${\displaystyle d}$ is the transit time for the Sync message, and ${\displaystyle {\tilde {o}}}$ is the constant offset between leader and follower clocks, then
${\displaystyle \ T{1}'-T{1}={\tilde {o}}+d{\text{ and }}\ T{2}'-T{2}=-{\tilde {o}}+d}$
${\displaystyle {\tilde {o}}={\frac {1}{2}}(T{1}'-T{1}-T{2}'+T{2})}$
The clock now knows the offset ${\displaystyle {\tilde {o}}}$ during this transaction and can correct itself by this amount to bring it into agreement with their leader.
One assumption is that this exchange of messages happens over a period of time so small that this offset can safely be considered constant over that period. Another assumption is that the transit time of a message going from the leader to a follower is equal to the transit time of a message going from the follower to the leader. Finally, it is assumed that both the leader and follower can accurately measure the time they send or receive a message. The degree to which these assumptions hold true determines the accuracy of the clock at the follower device.
Optional features
Precision Time Protocol
IEEE 1588-2008 standard lists the following set of features that implementations may choose to support:
• Alternate Time-Scale • Grand Master Cluster • Unicast Masters • Alternate Master • Path Trace
IEEE 1588-2019 adds additional optional and backward-compatible features:
• Modular transparent clocks • Special PTP ports to interface with transports with built-in time distribution • Unicast DelayReq and DelayResp messages • Manual port configuration overriding BMCA • Asymmetry calibration • Ability to utilize a physical layer frequency reference (e.g. Synchronous Ethernet) • Profile isolation • Inter-domain interactions • Security TLV for integrity checking • Standard performance reporting metrics • Slave port monitoring
Related initiatives
Precision Time Protocol
• The International IEEE Symposium on Precision Clock Synchronization for Measurement, Control and Communication (ISPCS) is an IEEE-organized annual event that includes a plugtest and a conference program with paper and poster presentations, tutorials and discussions covering several aspects of PTP. • The Institute of Embedded Systems (InES) of the Zurich University of Applied Sciences/ZHAW is addressing the practical implementation and application of PTP. • IEEE 1588 is a key technology in the LXI Standard for Test and Measurement communication and control. • IEEE 802.1AS-2011 is part of the IEEE Audio Video Bridging (AVB) group of standards. It specifies a profile for the use of IEEE 1588-2008 for time synchronization over a virtual bridged local area network as defined by IEEE 802.1Q. In particular, 802.1AS defines how IEEE 802.3 (Ethernet), IEEE 802.11 (Wi-Fi), and MoCA can all be parts of the same PTP timing domain. • SMPTE 2059-2 is a PTP profile for use in synchronization of broadcast media systems. • The AES67 audio networking interoperability standard includes a PTPv2 profile compatible with SMPTE ST2059-2. • Dante uses PTPv1 for synchronization. • Q-LAN and RAVENNA use PTPv2 for time synchronization. • The White Rabbit Project combines Synchronous Ethernet and PTP. • Precision Time Protocol Industry Profile PTP profiles (L2P2P and L3E2E) for industrial automation in IEC 62439-3 • IEC/IEEE 61850-9-3 PTP profile for substation automation adopted by IEC 61850 • Parallel Redundancy Protocol use of PTP profiles (L2P2P and L3E2E) for industrial automation in parallel networks • PTP is being studied to be applied as a secure time synchronization protocol in power systems' Wide Area Monitoring