Precision Time Protocol
IEEE 1588 Time Synchronization
IEEE 1588 time synchronization uses Precision Time Protocol (PTP) to align clocks across a network. Devices exchange timestamped messages, estimate communication delay and adjust their local clocks toward a shared timing reference.
The process accounts for the fact that a timing message takes time to travel. Its arrival time alone cannot reveal whether a receiving clock is incorrect or the message was delayed.
What IEEE 1588 Synchronizes
Each participating device has a local clock. Even when two clocks initially show the same time, differences in their oscillators can cause them to drift apart.
PTP provides repeated timing observations that a device can use to correct its clock. Two related quantities matter:
Time Offset
The difference between two clock readings at the same instant.
Frequency Error
The difference in the rates at which those clocks advance.
Correcting an initial offset brings clocks closer together. Controlling their relative rates helps keep them aligned between message exchanges.
How PTP Measures Clock Offset
A simplified end-to-end exchange uses four timestamps. This example assumes equal forward and reverse path delays, negligible clock-rate change during the exchange, and no additional correction terms.
| Timestamp | Event |
|---|---|
| t1 | The source clock sends a Sync message. |
| t2 | The receiving clock records the Sync message’s arrival. |
| t3 | The receiving clock sends a Delay_Req message. |
| t4 | The source clock records that request’s arrival and reports it in a Delay_Resp message. |
The forward measurement, t2 − t1, contains both network delay and clock offset. The reverse measurement, t4 − t3, contains the reverse delay with the offset acting in the opposite direction.
Under the stated assumptions:
[(t2 − t1) + (t4 − t3)] ÷ 2[(t2 − t1) − (t4 − t3)] ÷ 2A positive offset means the receiving clock is ahead of the source clock. The receiver uses repeated observations to guide its clock adjustments.
Real implementations also account for applicable correction information and use filtering and clock-control algorithms to manage changing measurements.
Why Timestamp Placement Matters
A timestamp should represent a defined point in a message’s transmission or reception.
Software Timestamping
Operating-system scheduling and packet processing can introduce variation between the timestamp and the message’s passage through the network interface.
Hardware Timestamping
Records events closer to the interface. This can reduce uncertainty caused by software processing, although the final synchronization result still depends on the rest of the timing path.
One-Step and Two-Step Operation
One-Step
The required precise transmission timing information is conveyed in the Sync message.
Two-Step
The Sync message is followed by a Follow_Up message carrying its precise origin timestamp.
These are different methods of delivering timing information. The number of messages alone does not establish which implementation will be more accurate.
Clock Roles in an IEEE 1588 Network
The timing path may include several types of PTP clock.
| Role | Function |
|---|---|
| Grandmaster | Provides the reference at the root of the PTP timing hierarchy. |
| Ordinary clock | Has one PTP port and can act as a source or receiver, depending on its capabilities and state. |
| Boundary clock | Synchronizes its local clock from an upstream source and provides timing through other PTP ports. |
| Transparent clock | Accounts for timing-message transit through a network device by updating correction information. |
A boundary clock participates in the timing hierarchy using its own synchronized clock. A transparent clock helps compensate for delay introduced as timing messages pass through it.
End-to-End and Peer-to-Peer Delay Measurement
PTP supports different ways to estimate communication delay.
End-to-End
Estimates the path delay between a receiving clock and its upstream timing source using delay-request and delay-response messages.
Peer-to-Peer
Estimates delay between adjacent PTP ports. Compatible devices use these link measurements together with the relevant correction information as timing messages travel through the network.
The selected profile and network implementation determine which mechanism is used. The four-timestamp example above describes the simplified end-to-end case.
Profiles and Domains
PTP Profiles
A profile defines how IEEE 1588 is used for a particular purpose. It can specify or restrict operating choices such as transport, message intervals, delay mechanisms and clock-selection behavior.
Two devices that both support IEEE 1588 may therefore require different configurations. Protocol support must be considered together with the applicable profile.
PTP Domains
A domain is a logical grouping of participating PTP instances that synchronize within a timing hierarchy.
Different domains can operate independently on shared infrastructure. A domain number helps distinguish their timing messages; it does not, by itself, provide network security or physical separation.
How the Grandmaster Is Selected
In PTP configurations using the Best Master Clock Algorithm, eligible clocks exchange information that allows them to determine the preferred timing source.
Selection considers configured priorities and advertised clock attributes according to the applicable algorithm. Profiles can modify or constrain this behavior.
If the selected source disappears or its advertised condition changes, another eligible clock may become the grandmaster. Selection, recovery time and the resulting timing disturbance depend on the implementation and configuration.
What Limits Synchronization Accuracy?
Unequal Path Delays
The simplified offset calculation assumes equal travel time in both directions. If the forward and reverse delays differ, part of that difference appears as clock-offset error.
For example, an uncompensated forward-versus-reverse delay difference of 200 nanoseconds produces a 100-nanosecond offset-estimation error under that model.
Variable Network Delay
Traffic and queuing can change message transit times. PTP-aware network devices, suitable topology and appropriate traffic handling can help control the resulting uncertainty.
Timestamp and Oscillator Performance
Timestamp resolution, interface implementation and local oscillator behavior influence how accurately a device measures and maintains time.
Clock-Control Behavior
The receiving device must turn timing measurements into stable clock adjustments. Filtering, correction rate and response to outliers affect convergence and ongoing performance.
IEEE 1588 support alone therefore does not guarantee a particular accuracy for every network.
Synchronization and UTC Are Different Requirements
A group of devices can closely agree with one another while sharing a reference that differs from UTC.
PTP distributes the timing reference provided through its hierarchy. Absolute accuracy to UTC also depends on the grandmaster’s reference and correct handling of the applicable timescale information.
This distinction matters when evaluating results: agreement between devices and accuracy to an external reference are separate measurements.
From Protocol Understanding to Hardware Selection
IEEE 1588 explains how compatible clocks exchange and use timing information. A working implementation also depends on the selected profile, clock roles and behavior of the network path.
For hardware configuration and purchasing enquiries, explore the PTP clock server range from HC Electronics.