PTP vs NTP for latency measurement

Clock synchronization is an error budget

Two clocks display the same number only within some uncertainty. Frequency error makes them drift. Network exchanges estimate offset, but asymmetric path delay looks like clock offset. Timestamp placement adds more error. A synchronization service controls these terms; it does not make them disappear.

Market-data measurements should define a maximum tolerable clock contribution. A strategy comparing feeds at 500 microsecond scale may accept tens of microseconds. A hardware-to-hardware path study at 5 microseconds cannot. Pick the measurement resolution first, then select PTP, NTP, GNSS, or a common-clock instrument capable of supporting it.

Status values are estimates rather than guarantees. chrony can report a root dispersion and system time offset. linuxptp can report master offset and path delay. Convert those into a conservative operational bound, include topology and timestamp uncertainty, and invalidate results when clock state leaves policy.

Clock error also affects log ordering, certificate checks, database leases, and time-based risk controls. A timing incident can therefore look like a network latency regression while damaging unrelated systems. Keep the synchronization acceptance signal separate from the feed process, and make measurement jobs consume it as a required dependency.

NTP estimates offset with four timestamps

The Network Time Protocol exchange uses client transmit time t1, server receive time t2, server transmit time t3, and client receive time t4. Under the symmetric-path assumption, the offset estimate is:

offset = ((t2 - t1) + (t3 - t4)) / 2

The round-trip delay estimate is:

delay = (t4 - t1) - (t3 - t2)

Network asymmetry biases the offset. If the forward path is 200 microseconds slower than the reverse path, the estimate can be wrong by about 100 microseconds even with perfect timestamping. Multiple sources, filtering, and long observation improve fault detection but cannot mathematically reveal unknown fixed asymmetry.

chrony disciplines the Linux system clock

chronyd is widely used on Linux because it handles intermittent links, variable delay, clock frequency estimation, and fast convergence well. chronyc tracking reports reference ID, stratum, system time offset, last offset, RMS offset, frequency, residual frequency, skew, root delay, root dispersion, and update interval.

chronyc sources -v shows source selection and reachability. The selection symbol identifies the current source or why another is excluded. The reach field is an octal shift register, with 377 indicating successful replies for the last eight polls. chronyc sourcestats reports sample count, run length, span, frequency, skew, offset, and standard deviation.

Monitor all three. A small current offset from one sample is weaker evidence than stable frequency, low dispersion, good reach, and agreement among independent sources. Save the output with every latency run.

NTP is sufficient for many operational clocks

NTP is practical across the public internet and ordinary routed networks. Software timestamps and variable paths often limit accuracy to fractions of a millisecond or several milliseconds, though well-engineered local NTP with hardware timestamps can do better. The deployment, not the protocol name, sets the result.

For log correlation, certificate validity, slot-level monitoring, and millisecond-scale service timing, chrony with several good sources is frequently appropriate. For comparing two feed arrivals separated by tens of microseconds, public NTP is generally an insufficient basis.

NTP's broad reach is also valuable as a sanity source for a PTP system. It can detect gross UTC errors or a failed grandmaster. Do not let two independent daemons discipline CLOCK_REALTIME simultaneously. Design which service owns which clock.

PTP distributes time inside a controlled domain

IEEE 1588 Precision Time Protocol elects or configures a grandmaster and exchanges timing messages with ordinary, boundary, and transparent clocks. Hardware timestamping at NIC ingress and egress removes much of host scheduling and driver delay from the exchange. A controlled switched network can reach sub-microsecond synchronization under suitable equipment and configuration.

PTP is not inherently accurate on any Ethernet network. Ordinary switches can add asymmetric queueing. Boundary clocks terminate and regenerate PTP on ports. Transparent clocks measure residence time and correct messages. The chosen PTP profile, domain number, transport, delay mechanism, priority, and announce behavior must agree across the domain.

Public internet routing is not a credible generic PTP domain. PTP belongs on an engineered LAN, cross-connect environment, or provider timing service with an explicit contract.

PHC and system time are separate clocks

A timestamp-capable NIC contains a PTP hardware clock exposed as /dev/ptp0 or another index. ethtool -T eth0 reports the associated PTP Hardware Clock number and supported timestamp modes. The PHC can follow the PTP grandmaster while CLOCK_REALTIME remains separate.

linuxptp's ptp4l synchronizes the PHC to the PTP domain in a common hardware-timestamped setup. phc2sys then synchronizes the system clock to the PHC, or performs another configured relation. Reversing source and destination accidentally can pull the good clock toward the bad one.

Applications using raw hardware timestamps must know their PHC domain and conversion. Applications using CLOCK_REALTIME need phc2sys or another discipline to align system time. Applications using CLOCK_TAI also need the correct UTC-to-TAI offset in the kernel.

ptp4l exposes servo state and offsets

ptp4l selects a clock, processes Sync, Follow_Up, Delay_Req, Delay_Resp, announce, and related messages according to configuration. Output lines report master offset, path delay, frequency adjustment, and port state. The state should reach SLAVE for a client port under the ordinary master terminology used by existing tools.

A line such as master offset 120 s2 freq -342 path delay 811 means an estimated 120 ns offset in servo state s2, a frequency adjustment, and an 811 ns mean path delay under that output format. One line is not a bound. Track the distribution and state transitions.

pmc queries PTP data sets from a running linuxptp management interface. GET PORT_DATA_SET shows port state. GET TIME_STATUS_NP shows fields such as master_offset, gmPresent, and gmIdentity. GET TIME_PROPERTIES_DATA_SET reports UTC offset and leap flags.

Delay mechanism and transport must match

End-to-end delay uses Delay_Req and Delay_Resp between an ordinary clock and its master. Peer-to-peer delay measures each adjacent link with Pdelay messages and requires compatible network design. A mismatch can prevent synchronization or produce misleading state.

PTP can run directly over Ethernet Layer 2 or over UDP IPv4 and IPv6, depending on profile and configuration. The linuxptp ptp4l -2 option selects Layer 2 transport, while -4 selects UDP IPv4. Firewalls, multicast handling, VLAN priority, and switch support differ.

Use the profile required by the timing provider or grandmaster. Telecom, power, broadcast, and datacenter profiles have different assumptions. A default ptp4l invocation is not a universal interoperable configuration.

UTC, TAI, and leap seconds need explicit handling

PTP commonly distributes a timescale related to TAI along with currentUtcOffset and time properties. Linux CLOCK_REALTIME represents UTC-like civil time, while CLOCK_TAI adds the configured TAI offset without leap discontinuities. The kernel TAI value can be inspected through adjtimex output and clock APIs.

If currentUtcOffset is wrong or unavailable, phc2sys can place system time an integer number of seconds away from reality. A latency subtraction across hosts may still look plausible if both share the same error, while logs disagree with external systems. Verify both absolute time and relative offset.

Leap insertion or deletion can cause a step, smear, or other controlled behavior depending on the timing service. Mixing a smeared NTP source with a non-smeared PTP source creates disagreement around the event. Document the time policy before the leap window.

Hardware timestamp support has several levels

ethtool -T lists SOF_TIMESTAMPING capabilities and receive filters such as ptpv2-event or all. Some NICs timestamp only PTP event messages, which is enough for clock synchronization but not arbitrary market-data packets. Others can timestamp all receive frames or selected flows. Driver support determines what reaches SO_TIMESTAMPING.

One-step PTP inserts the transmit timestamp or correction as the Sync message leaves. Two-step PTP sends a Follow_Up containing the precise time. Hardware and switch support differ. Both can be accurate when the domain is configured coherently.

Software timestamped PTP can synchronize a local network better than public NTP in some cases, but host scheduling and queue asymmetry remain. Do not label a software ptp4l deployment as hardware PTP because the NIC has a PHC that the process did not use.

Asymmetry is the hard limit

Both NTP and basic PTP offset calculations assume related forward and reverse delays. Fiber length difference, different switch paths, queue policy, media converters, and routing can make them unequal. Half the asymmetry appears as clock-offset error.

PTP-aware transparent and boundary clocks reduce variable residence uncertainty. Calibrated fiber and hardware asymmetry corrections address fixed differences in precision deployments. Network priority reduces queueing but does not prove symmetry.

Test by swapping ports, paths, or master and client roles. Stable sign changes can reveal a directional component. A common-clock time interval counter or calibrated capture equipment provides stronger verification. Servo-reported low offset alone cannot expose equal and opposite measurement bias.

Holdover determines behavior after source loss

When timing packets stop, the local oscillator continues at its last estimated frequency. This is holdover. Clock error then grows according to oscillator stability, temperature, aging, and the quality of the previous frequency estimate. A standard server crystal can drift far faster than an oven-controlled oscillator.

Monitoring must alert on source state immediately and calculate how long the clock can remain within the measurement budget. A PTP port leaving SLAVE, gmPresent becoming false, chrony losing selected sources, or root dispersion crossing a limit should invalidate new one-way measurements.

Do not step the clock automatically in the middle of a trading process without understanding timer behavior. chrony makestep policies and phc2sys step thresholds belong in the startup and operations design. Slewing takes longer but preserves monotonic progression of CLOCK_REALTIME under normal adjustments.

Security and failure domains differ

NTS adds authenticated key establishment and protects NTP exchanges with modern cryptography where clients and servers support it. Traditional unauthenticated NTP can be spoofed or redirected. Source diversity and network policy reduce, but do not eliminate, that risk.

Many PTP domains rely on physical or VLAN isolation and profile-specific controls rather than strong message authentication. A rogue better grandmaster can win the Best Master Clock Algorithm and move the domain. Static master configuration, priority policy, switch filtering, and monitoring of gmIdentity are important.

Time is production input. Alert on grandmaster identity changes, offset, path delay, frequency, state, UTC offset, source reach, and daemon restart. A clock failure can corrupt latency evidence across every otherwise healthy feed.

Retain raw state at a cadence faster than the shortest permitted bad interval. A one-minute average can hide a three-second grandmaster switch that invalidates thousands of packet samples. Timestamp the monitoring observation from a clock independent enough to diagnose a local step, or write monotonic durations beside civil timestamps.

Choose from the required accuracy and topology

Use public or provider NTP for general host time when millisecond uncertainty is acceptable. Use well-engineered local NTP with hardware timestamps where its measured bound fits. Use PTP with hardware timestamping and aware network equipment for microsecond or sub-microsecond synchronization inside a controlled domain.

GNSS at each host or a timing appliance can reduce dependence on network symmetry, but antenna, holdover, calibration, and spoofing become new concerns. A common hardware clock or capture appliance is strongest for laboratory validation.

For one-way shred latency, record clock state beside every sample interval. Without a sender timestamp and synchronized endpoint, only receiver-local timing is available. Clock quality cannot create a missing publication timestamp.