IEEE 1588 PTP synchronisation: hardware timestamping and the error budget

The IEEE 1588 Precision Time Protocol (PTP) derives clock offset from four timestamps and assumes equal path delay in both directions; any violation enters the offset at half its size and is invisible in the protocol's own statistics. This note derives the t1–t4 equations, builds a numeric error budget from vendor data on the timestamping layer, switches, asymmetry, servo and oscillator, and covers verification, common pitfalls and White Rabbit.

Notation and scope

Offset is θ = slave − master (timeReceiver − timeTransmitter in current documents [13]). One-way delays are d_ms and d_sm, their mean d̄, the asymmetry Δ = d_ms − d_sm. Derived numbers are marked.

End-to-end delay measurement and the t1–t4 equations

In the delay request-response (E2E) mechanism the master timestamps the departure of Sync as t₁ and the slave its arrival as t₂. Two-step operation sends t₁ in a Follow_Up; one-step hardware writes it into the Sync frame on the fly. The slave then sends Delay_Req (t₃); the master timestamps its arrival (t₄) and returns it in Delay_Resp [1].

Deriving offset and mean path delay

Taking the master as reference, t₂ = t₁ + d_ms + θ and t₄ = (t₃ − θ) + d_sm:

Eidson calls this “two measured quantities, three unknowns” and closes it by assuming d_ms = d_sm [1]. Subtracting and adding:

The Intel I210 datasheet uses the same delay expression in its clock adjustment example [5].

Why asymmetry appears as Δ/2

Inserting the true delays of (1) into (2):

A constant asymmetry leaves d̂ plausible and is unobservable from inside the protocol. Nokia states the offset error as half the delay difference [13], Cisco as “every 2 μs of asymmetry = 1 μs of time error” [14], and Meinberg notes that the offset seen against GNSS is half the asymmetric delay [12]. Only an external time reference can measure it.

Effect of frequency offset

With slave frequency offset y, θ(T) = θ₀ + y·T; with T₂, T₃ the true Sync arrival and Delay_Req departure times, the same steps give:

Before lock (y = 10 ppm, 0.5 s between messages) the delay error is 2.5 μs; after lock (y ≈ 1 ppb) it is 0.25 ns (derived). Hence the servo acquires frequency first; linuxptp steps the clock once if the first offset exceeds 20 μs (first_step_threshold) [7].

Peer-to-peer delay mechanism

In P2P the two ends of each link measure only that link with Pdelay_Req / Pdelay_Resp / Pdelay_Resp_Follow_Up [3][11]. As t₃ − t₂ is measured on the responder's clock, offset cancels but the frequency ratio does not:

r converts a responder-clock interval to the requester's timescale; ignoring it costs y·(t₃ − t₂)/2, 50 ns for 10 ppm and a 10 ms turnaround (derived). linuxptp estimates it over freq_est_interval (default 2 s) [7]. A P2P transparent clock (TC) adds its residence time and the ingress link delay to the Sync correctionField [3][4]; the slave subtracts only the last link:

With P2P the master need not answer every slave's Delay_Req and link delays are known before a topology change, but every switch must be 1588-capable [11].

Where the timestamp is taken

t₁…t₄ should be the instants a frame leaves and enters the medium. Every component between that point and the timestamp turns its delay variation into noise and its direction-dependent mean into asymmetry. TI notes that software adds the most error, through processor load and interrupt latency [2].

Error sources of software timestamps

The Linux kernel takes the receive software timestamp just after the driver hands the packet to the stack, and the transmit one in the driver just before the packet goes to the interface [6]. DMA, interrupt coalescing, interrupt latency and NAPI polling thus fall inside the receive error; descriptor fetch, NIC queueing and a frame already on the wire inside the transmit error, all load-dependent. TI reports about 100 μs on a single link for software PTP (100–10 μs in its Figure 1) and says the nanosecond region needs hardware assistance [2]; EndRun quotes 10–100 μs [10].

MAC and PHY timestamps: fixed and variable latency

In the Intel I210 the timestamp logic sits “as close as possible to the PHY interface” and samples the start of the packet [5]. The latency to the MDI lies outside the timestamp and is characterised only at 100 Mb/s: 984/1024 ns transmit timestamp to SFD (min/max over reset or link up/down), 2148/2228 ns SFD to receive timestamp (jitter from clock-domain synchronisation), averaging 1044 and 2133 ns with a commercial partner; the timer nominally steps 8 ns (125 MHz) with a sub-nanosecond fraction [5]. With TX/RX the latency between timestamp and wire, (1) gives:

Identical ends cancel, so bench tests with two cards of one model look optimistic. If the master is corrected and an I210 slave is not, the error is (2133 − 1044)/2 ≈ 544 ns (derived). linuxptp provides ingressLatency and egressLatency for the correction [7]. The Linux igb driver already applies speed-dependent I210 constants (1024 ns transmit, 2213 ns receive at 100 Mb/s) [22], so the example fits drivers that do not; adding ptp4l latencies on top corrects twice. PHY timestamping puts most of this latency inside the timestamp: in TI's DP83640 single-cable tests 1PPS outputs differed by −869 ps mean, 7.87 ns standard deviation; 10 MHz outputs by −226 ps, 2.655 ns, 11 ns peak to peak (1 s Sync, 25 MHz crystal, 25 °C; no network, temperature change or mixed vendors) [2].

Timestamp quantisation

With a counter of resolution g and a phase that is random relative to packet arrival, the error is uniform over g with standard deviation g/√12. Equation (2) combines four timestamps with a factor 1/2:

For g = 8 ns this is 2.31 ns, or 3.27 ns when the offset uses only the two Sync-path timestamps with a filtered delay (derived). Garner's simulations used 8 ns granularity for telecom and 40 ns for 802.1AS [15]. If both ends share a frequency source (e.g. Synchronous Ethernet), arrival phase does not walk through the counter period and the error becomes a fixed bias of up to ±g/2 instead of averaging out (derived).

Network-induced error: packet delay variation and asymmetry

Queueing and PDV

In a PTP-unaware switch an event message waits behind the frame on the wire and the queue ahead of it. One maximum-size frame (1538 bytes with preamble and gap, 12 304 bits) costs 123 μs at 100 Mb/s and 12.3 μs at 1 Gb/s (derived). The wait varies per packet and its mean differs by direction, so packet delay variation (PDV) is both noise and asymmetry. In Eidson's compilation, a plain switch gave 121 ns offset standard deviation with −430/+720 ns extremes over 8 hours; boundary-clock switches gave 24 ns (±100 ns, 84 hours) and 15 ns (−35/+45 ns, 1 hour), at 20–25 ns clock resolution [1]. Cisco notes that PDV accumulates at every unaware node [14].

Transparent and boundary clocks

An E2E TC adds the time between its ingress and egress timestamps to the correctionField [3], a 64-bit field that Microchip says can in principle carry switch delay to better than a picosecond [4]. What remains is the error of the TC's own two timestamps per traversal, plus its frequency error times residence time: 1.2 ns for 10 ppm and 123 μs (derived), which is why TI recommends syntonising TC clocks to the grandmaster [3]. A boundary clock (BC) terminates PTP, acting as slave on one port and master on the others [3]; PDV is reset at every BC [14], but servo noise and constant time error (cTE) accumulate. In Garner's simulations (BC bandwidth 0.1 Hz, 0.1 dB peaking) the dynamic component over 21 hops without SyncE rearrangements stayed within its 200 ns budget, at 118 ns and 88 ns [15].

Sources of asymmetry

Link speed mismatch. A store-and-forward switch forwards only after receiving the whole frame, so it adds at least L/R_in between start-of-frame timestamps. With the master on 1 Gb/s and the slave on 100 Mb/s, Sync enters the fast port and Delay_Req the slow one; for equal lengths L:

Sync and Delay_Req are 44 bytes, a 34-byte header plus a 10-byte originTimestamp [21], i.e. 90-byte (720-bit) frames over UDP/IPv4: Δ = 0.72 − 7.2 = −6.48 μs and the offset error is −3.24 μs (derived). A TC measures this as residence time and removes it.

Cable and fibre. Twisted pairs differ in twist rate and hence delay; Fluke gives limits of 570 ns delay and 50 ns delay skew for links up to 100 m [20]. 100BASE-TX transmits and receives on different pairs, so skew is asymmetry: ≤25 ns offset error at the limit (derived). Fibre using a different wavelength per direction is asymmetric through refractive index; the White Rabbit calibration procedure defines α = (δ_ms − δ_sm)/δ_sm and measures 2.573·10⁻⁴ on 5 km of fibre with 50.42 μs round-trip latency [18], i.e. ≈6.5 ns one-way difference and ≈3.2 ns offset error if ignored (derived).

End hardware and routing. The mismatch in (8) can reach hundreds of nanoseconds with mixed vendors and speeds; Cisco adds routing (rings, ECMP), unaware transit nodes and transports such as PON and DWDM [14]. In linuxptp a measured asymmetry goes into delayAsymmetry, positive when master-to-slave propagation is longer [7].

Clock servo and oscillator

The linuxptp PI servo

The default ptp4l servo is a PI controller [7]; in the locked state its frequency correction (ppb) is computed from the offset (ns) as [8]:

s is the Sync interval; constants are the hardware defaults (software: 0.1 and 0.001) [7][8], giving k_p = 0.7, k_i = 0.3 at 1 s and 1.306, 0.131 at 1/8 s. A 1 ppb correction held for s seconds shifts phase by s ns, so the loop is x_n+1 = x_n − s·u_n. With the proportional term only and white measurement noise σ_v:

At s = 1 s the ratio σ_x/σ_v is 0.73. Adding the integral term, the stationary variance of a simplified model built from (11) and this loop (white Gaussian measurement noise, no oscillator noise, ptp4l's filters and state machine left out) gives 1.05 at 1 s, 0.39 at 1/8 s and 0.30 at 1/16 s (derived, not measured on ptp4l): at default gains and 1 s the servo barely filters, since the gains favour fast acquisition. A higher Sync rate gives more samples with smaller per-sample gain; Garner's telecom simulations used 8 Hz Sync and 1 Hz Delay_Req [15], at the cost of CPU, timestamp and Delay_Resp load [11]. The delay is filtered separately, by default with a 10-sample moving median [7].

If frequency drifts at r ppb/s (a temperature ramp), the integral term must grow by r·s per sample; from k_i·x_ss = r·s:

Vig lists a TCXO temperature stability of 5·10⁻⁷ over −55 to +85 °C [16], ≈3.6 ppb/K on average (local slopes can be steeper). At 1 K/min, r ≈ 0.06 ppb/s and x_ss ≈ 0.2 ns with hardware gains, ≈60 ns with software gains (k_i = 0.001) (derived).

Oscillator stability and Allan deviation

Short-term stability is specified by the Allan deviation; for fractional frequencies ȳ_k averaged over τ:

Vig's table lists σ_y(1 s) of 1·10⁻⁹ for a TCXO and 1·10⁻¹² for an OCXO, ageing of 5·10⁻⁷ and 5·10⁻⁹ per year [16]. Taking phase wander between updates as roughly τ·σ_y(τ) gives ≈1 ns (TCXO) and ≈1 ps (OCXO) at 1 s (derived; exact relation depends on noise type). The term matters mainly in holdover:

A 200 ns holdover allowance lasts 200 s with y₀ = 10⁻⁹ and 20 s with 10⁻⁸ (derived); at the slope above, 10⁻⁸ corresponds to a 3 K change for a TCXO.

Error budget

Table 1 covers (a) ends connected directly and (b) one E2E TC in between, assuming 100BASE-TX, I210-class MAC timestamping (8 ns counter, 100 Mb/s latency data), a TC of the same class, cables up to 100 m, a TCXO slave, linuxptp default gains, and offset from the Sync path with filtered delay. Receive jitter is taken as uniform over 80 ns per packet; the datasheet states neither the distribution nor whether it varies per packet (if fixed per link-up, the term becomes a bias). The table does not replace characterisation; it shows the dominant term and what calibration can remove.

Table 1. Example PTP error budget. σ: 1σ random term; ±: bounded bias.

With MAC timestamps at 100 Mb/s the random term comes from the receive clock-domain crossing, not counter resolution, consistent with PHY timestamping reaching 2.7–7.9 ns on one link [2]. Even after calibration the biases exceed the random terms, and neither the servo nor the ptp4l log shows them. Without TCs and with mixed link speeds, one asymmetry source outweighs everything else by microseconds.

Comparison with telecom profile targets

ITU-T G.8271.1 sets network limits for full timing support; open sources quote ±1.5 μs end to end with ±1.1 μs for network equipment [13][14], and Table 2 gives Nokia's allocation [13]. For G.8273.2 boundary clock classes, maximum absolute time error (max|TE|) and cTE are quoted as 100 ns and ±50 ns (Class A), 70 ns and ±20 ns (Class B) [14][23]. Case (b) of Table 1 is of the same order as these per-node limits, hence telecom equipment relies on characterised, calibrated PHY timestamp paths.

Table 2. One allocation of the ±1.5 μs end-to-end budget (Nokia's summary of G.8271.1)

Verification methods

1PPS and clock outputs. Master and slave 1PPS outputs are compared on a time interval counter; a Keysight 53230A-class counter resolves 20 ps [19]. The real uncertainty lies elsewhere: TI notes that 1PPS samples once per second, uncorrelated with clock updates, through a digital output adding its own error, and prefers comparing 10 MHz clock outputs [2]. White Rabbit requires measurement cables of equal length and type or known delay [18]; swapping cables measures path delays.

External reference and calibration. For separated nodes a GNSS-disciplined reference is used at both ends; by (4) the slave's offset against GNSS is half the asymmetry [12], with the receiver's 1PPS uncertainty and antenna cable delay (from its datasheet) in the same budget. End latencies can follow the White Rabbit template: a calibrator device, known fibre, and a measured 1PPS skew that corrects transmit and receive latencies [18].

PDV injection. Switch ports are loaded with maximum-size frames, or a network emulator adds a defined delay distribution, including direction-dependent load; otherwise only noise, not asymmetry, is measured.

Temperature. The slave and any TC are swept in a climatic chamber to expose oscillator and PHY latency drift. White Rabbit reports a 128 ps standard deviation of 5 km fibre round-trip delay over about 12 hours from temperature (2.81 ps for 5 m) and warns that a one-off calibration may not hold at another ambient temperature [18]. Runs should span several temperature cycles, reporting constant and filtered dynamic error separately.

Common pitfalls

• Assuming zero asymmetry. Every 2 ns of asymmetry is 1 ns of invisible error; mixed-speed ports, mixed-vendor PHYs and dual-wavelength fibre must be measured.
• Relying on software timestamps. They give 10–100 μs [2][10]; check hardware capability with ethtool (SOF_TIMESTAMPING_RAW_HARDWARE etc.) [9].
• Confusing the PHC with the system clock. With hardware timestamps ptp4l disciplines the NIC's PTP hardware clock (PHC); phc2sys then synchronises the system clock to it [9], a second stage that needs its own measurement.

Sub-nanosecond: White Rabbit

White Rabbit, an open PTP extension from CERN and partners, combines PTP, physical-layer frequency transfer via Synchronous Ethernet (SyncE), and clock loopback with phase measurement [17]: the slave's recovered clock is cleaned by a digital PLL based on dual mixer time difference (DMTD) (reported jitter 2.5 ps) and returned to the master, which measures the phase difference and sends it to the slave. On a chain of four switches with 5 km of fibre each, heated with a hot-air gun, accumulated skew stayed well below 1 ns with a standard deviation around 6 ps [17].

That accuracy rests on calibration: each device's transmit/receive latencies (SFP, PCB, FPGA) and the fibre's α are measured, and the uncertainty in α alone leaves ≈9 ps of asymmetry on 5 km [18]; both link ends must implement White Rabbit [17]. The lesson holds for standard PTP too: below a nanosecond, calibration of fixed latencies and asymmetry, not resolution, sets the budget.

References

1. J. C. Eidson, “Recent Advances in IEEE 1588 Technology and Its Applications,” IEEE 802.3 ResE SG presentation, 2005. https://grouper.ieee.org/groups/802/3/re_study/public/200507/eidson_1_050719.pdf
2. Texas Instruments, “AN-1728 IEEE 1588 Precision Time Protocol Time Synchronization Performance,” SNLA098A, 2013. https://www.ti.com/lit/an/snla098a/snla098a.pdf
3. Texas Instruments, “AN-1838 IEEE 1588 Boundary Clock and Transparent Clock Implementation Using the DP83640,” SNLA104A, 2013. https://www.ti.com/lit/pdf/snla104
4. Microchip, “ENT-AN1132 Transparent Clock Mode Support,” VPPD-03802, 2018. https://ww1.microchip.com/downloads/en/Appnotes/VPPD-03802.pdf
5. Intel, “Ethernet Controller I210 Datasheet,” rev. 3.7, 2021, §7.8.3. https://cdrdv2-public.intel.com/333016/333016%20-%20I210_Datasheet_v_3_7.pdf
6. Linux kernel documentation, “Timestamping.” https://docs.kernel.org/networking/timestamping.html
7. linuxptp, “ptp4l(8).” https://linuxptp.nwtime.org/documentation/ptp4l/
8. linuxptp source code, “pi.c.” https://raw.githubusercontent.com/richardcochran/linuxptp/master/pi.c
9. SUSE, “Precision Time Protocol,” SLES 15 SP7 System Analysis and Tuning Guide. https://documentation.suse.com/sles/15-SP7/html/SLES-all/cha-tuning-ptp.html
10. EndRun Technologies, “What is the difference between PTP hardware and software timestamping?” https://endruntechnologies.com/node/249
11. Meinberg, “End-to-End Versus Peer-to-Peer,” 2013. https://blog.meinbergglobal.com/2013/09/19/end-end-versus-peer-peer/
12. Meinberg, “Measuring Asymmetric Delay in the networks,” 2014. https://blog.meinbergglobal.com/2014/05/12/asymmetric-network-delay-ntp/
13. Nokia, “IEEE 1588 for Frequency, Phase, and Time Distribution,” Advanced Configuration Guide 23.7.R2. https://documentation.nokia.com/acg/23-7-2/books/classic-cli-part-i/c072-acg-ieee-1588-fp-td.html
14. Cisco, “Synchronizing 5G Mobile Networks,” Cisco Live EMEA 2024, BRKSPG-3050. https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2024/pdf/BRKSPG-3050.pdf
15. G. M. Garner, “IEEE 1588 Simulations – G.827x and 802.1AS,” Joint IEEE-SA/ITU Workshop on Ethernet, 2013. https://www.itu.int/en/ITU-T/Workshops-and-Seminars/ethernet/201307/Documents/S3P3_Geoff_Garner_V2.pdf
16. J. R. Vig, “Quartz Crystal Resonators and Oscillators — A Tutorial,” SLCET-TR-88-1 rev. 8.4.2, U.S. Army CECOM, 2000. https://www.am1.us/wp-content/uploads/Documents/U11625_VIG-TUTORIAL.pdf
17. P. P. M. Jansweijer, H. Z. Peek, E. de Wolf, “White Rabbit: Sub-Nanosecond Timing over Ethernet,” NIM A preprint, 2012. https://indico.cern.ch/event/143656/papers/1378076/files/1031-WHITE.pdf
18. G. Daniluk, “White Rabbit calibration procedure, version 1.1,” CERN, 2015. https://white-rabbit.web.cern.ch/documents/WR_Calibration-v1.1-20151109.pdf
19. Keysight, “53230A Universal Frequency Counter/Timer,” product page. https://www.keysight.com/us/en/product/53230A/350-mhz-universal-frequency-counter-timer-12-digits-s-20-ps.html
20. Fluke Networks, “Network Cable Propagation Delay.” https://www.flukenetworks.com/knowledge-base/dtx-cableanalyzer/propagation-delay
21. linuxptp source code, “msg.h” (Sync and Delay_Req message structures). https://raw.githubusercontent.com/richardcochran/linuxptp/master/msg.h
22. Linux kernel source, igb driver, “igb.h” (I210 latency constants; applied in igb_ptp.c). https://raw.githubusercontent.com/torvalds/linux/master/drivers/net/ethernet/intel/igb/igb.h
23. S. Ruffini, S. Rodrigues, “Distribution of Timing: Sync over the Packet Layer of Networks,” ATIS WSTS tutorial, 2022, p. 14. https://wsts.atis.org/wp-content/uploads/2022/05/09-Stefano-Ruffini.Silvana-Rodrgues.Distribution-of-Timing-Over-the-Packet-Layer-of-Networks.pdf