NTP vs. PTP: When Distributed Devices Need the Same Time Base

Matching timestamps are not yet a common time base

A timestamp initially describes what a particular clock showed at a particular moment. When events from several devices are brought together, a second question arises: How do those clocks relate to one another?

This becomes relevant as soon as several technical sources describe the same operation. A scale records a mass, a camera documents the state at the workstation, a scanner assigns a container, and a terminal records a confirmation. Each system can provide its own time. That alone does not establish whether those timestamps may be sorted directly against one another.

For later reconstruction, several points therefore have to remain distinct: Which clock produced a timestamp? Where does that clock obtain its time? How far may it deviate from the other clocks involved? And what temporal distinction does the process actually require?

NTP vs. PTP: The difference is not only accuracy

NTP and PTP are used to relate clocks in a network to a common time base. For process architecture, however, they differ not only in how closely two clocks can be aligned. Another decisive factor is how deeply the network itself is involved in synchronization.

A review article in IEEE Access by Idrees et al. describes the PTP side of this difference primarily in architectural terms: grandmaster, different clock types, hardware timestamping, and compensation for network delays work together.^[3]

The comparison therefore does not answer which protocol is generally better.

How NTP aligns clocks

The Network Time Protocol is designed to synchronize computer clocks over networks. RFC 5905 describes a hierarchical structure: primary time servers sit at the root, while secondary servers and clients obtain time through additional levels. This hierarchy is expressed as a stratum; the RFC identifies stratum 16 as unsynchronized.^[1]

Assessing a time source therefore involves more than the clock value most recently set. RFC 5905 distinguishes, among other things, offset, delay, dispersion, and jitter. Offset describes the determined time difference between the server clock and the system clock; delay is the round-trip communication time. Dispersion represents an error bound of the measurement, while jitter describes variation between successive offset values.^[1]

NTP can also evaluate several possible sources against one another. The selection algorithm rejects candidates regarded as faulty and continues with the remaining suitable sources. Synchronization therefore involves not only adopting a time value but also evaluating the sources from which that time is derived.^[1]

One limit remains the transmission path itself. Calculating the time offset assumes that network delay is approximately symmetric in both directions.^[2]

How PTP distributes time across a network under IEEE 1588

PTP, the protocol defined by IEEE 1588, distributes time hierarchically from a common reference to other clocks in the network. The grandmaster acts as the central time source. A Best Master Clock algorithm can determine which clock takes that role.^[3]

The literature distinguishes several clock types. An Ordinary Clock is the local clock of an end device. A Boundary Clock sits between the master and downstream clocks and carries synchronization across intermediate nodes. A Transparent Clock, by contrast, measures how long a PTP message remains in an intermediate node and carries that residence time in a correction value.^[3]

For synchronization itself, the master and the downstream clock exchange timestamped messages. The master sends a Sync message with its transmission time. In a two-step procedure, a Follow_Up message carries the precise timestamp. The downstream clock records reception, then sends Delay_Req, and the master reports the reception time back in Delay_Resp. These times can be used to determine offset and mean path delay.^[3]

For achievable synchronization quality, where the timestamp is created matters. Hardware timestamping can occur closer to the physical interface and thereby reduce the influence of operating-system latency.

PTP does not eliminate uncertainty, however. Its path-delay calculation also assumes that forward and reverse paths are sufficiently symmetric—an assumption that, according to the literature, is generally not exactly true in real networks. Queuing in switches, transmission and processing delays, and drift of local oscillators therefore remain relevant sources of error.

PTP is therefore not simply a more accurate version of NTP. It incorporates parts of the network infrastructure more directly into synchronization.^[3]

When NTP is sufficient—and when PTP may become necessary

A rule of thumb such as “PTP from one millisecond onward” asks the wrong question. The first issue is which events must later still be distinguished reliably from one another or correlated with one another.

If a scale delivers a value and an approval occurs several seconds later, greater temporal uncertainty may be tolerable than in an operation where a camera image, a measured value, and a machine state belong together within a very narrow time window.

Three questions are therefore particularly important for the selection:

• How close together can events occur whose sequence still needs to be distinguished reliably?
• Do the relevant timestamps come from several independent clocks and network paths?
• What should happen if the required synchronization quality is no longer achieved?

NTP can be sufficient when the synchronization quality actually achieved in the specific network is clearly within what the process requires.

PTP may become relevant when the network path, intermediate components, and timestamping point themselves become part of the required temporal accuracy.

The literature also shows how strongly implementation matters: for hardware-assisted PTP timestamping, deviations down to about 100 nanoseconds are reported; for software-only timestamping, 10 to 100 microseconds. These are reported values from individual implementations, not a guaranteed property of the protocol. The way timestamps are generated alone can therefore change the synchronization quality actually achieved by orders of magnitude.

Network components remain relevant as well. PTP-capable switches and routers may be required for particularly tight synchronization requirements.^[3]

The protocol does not determine the time quality a process needs. The process determines which synchronization architecture must deliver that quality.

Timestamps are not synchronized clocks

A device value can carry more than one time reference. In a DataValue, OPC UA can include a SourceTimestamp and a ServerTimestamp alongside the value itself.^[4]

The SourceTimestamp identifies the time assigned to the value by the data source. If the value is passed through another OPC UA server, that source timestamp is preserved. The ServerTimestamp, by contrast, describes the time at which the respective server received the value or knew it to be accurate. Two time values can therefore coexist without either being wrong.^[4]

For time synchronization, this distinction is important. OPC UA specifies that the SourceTimestamp should be generated as close as possible to the data source and always by the same physical clock. This keeps the provenance of the time reference consistent. It does not yet establish that this clock runs sufficiently close to the clock of a second device.

At the IoT gateway, SourceTimestamp and reception time are available side by side. Keeping them separate creates the basis for later determining which clock produced which time and how that time entered the process.^[4]

A complete timestamp therefore answers the question “When, according to this source?” The further question is: How reliably can this time be compared with the times of other sources?

What the system needs to know about its own time

A reliable time base has a state of its own. NTP explicitly defines the state unsynchronized. OPC UA provides for the SourceTimestamp to be set to null when the source that generates that timestamp is unavailable. A missing or uncertain time reference should therefore not silently be replaced by the last known state.^[1][4]

There is also the question of whether the time source can be trusted at all. Network Time Security can protect NTP cryptographically. RFC 8915 lists, among other goals, authenticity of synchronization packets and detection of replayed packets.^[2]

This protection does not solve every timing problem. In an asymmetric delay attack, an attacker can delay synchronization packets by different amounts. The packet contents need not be modified and their order need not be changed. Because the NTP calculation assumes approximately symmetric network delays, the client can nevertheless calculate an incorrect time offset. RFC 8915 explicitly states that cryptographic means cannot practically eliminate this attack.

The resulting error is limited, however: to at most half the round-trip delay. Multiple time sources or different network paths can further reduce the risk.

Trustworthy transmission and sufficiently accurate time are therefore two different requirements.^[2]

What the process architecture must define

The choice of synchronization technology should come at the end of a functional definition, not at its beginning.

The three selection questions lead to concrete requirements: The process must determine what temporal resolution its decisions require, which technical sources are to be compared, and what their time information is based on. It must also be defined how a known deviation or loss of the time source is handled and what information about the time reference remains stored together with an event.

21 CFR 11.10(e) requires time-stamped audit trails.^[5] PIC/S PI 041-1 requires that it be possible to identify who performed an activity and when.^[6] Neither document specifies the method or accuracy with which the clocks involved must be related to one another. Establishing a reliable temporal classification therefore remains a requirement that the operator has to derive from the process.

A suitable architecture must therefore do more than store a point in time. It must also be designed so that the time base on which that value rests, and the state of that time base, remain identifiable.