IEEE 1588/PTP Hardware Timestamping (One/Two-Step, Correction)
← Back to:Reference Oscillators & Timing
Hardware timestamping makes IEEE 1588/PTP measurable and repeatable by capturing time at a defined wire-level event boundary, not inside a best-effort software stack. This page turns one-/two-step timestamps, delay correction, and servo discipline into testable checks and pass criteria for robust ns-class synchronization.
What “Hardware Timestamping” Really Means in IEEE 1588
Hardware timestamping means the system records time at a clearly defined physical event boundary (for example, Ethernet frame start, a MAC/PHY interface boundary, or a PCS/PMD-level event), so the timestamp noise is dominated by clock quality and quantization—not by CPU scheduling, interrupts, or software queues.
A) Definition that can be verified
- Event boundary: the capture point is tied to a deterministic L1/L2 event (e.g., SFD / ingress / egress boundary), not “when software notices a packet.”
- Deterministic readout: timestamps are delivered through a controlled path (TSU → FIFO/queue → driver API) that preserves ordering and pairing.
- Observable repeatability: under identical conditions, timestamp variance is stable and explainable by clock noise + capture quantization, not by system load.
B) Why software timestamps are not enough
- Queueing variability: NIC rings, DMA batching, and coalescing introduce load-dependent delay and long-tail jitter.
- Interrupt and scheduling latency: preemption and IRQ handling add non-deterministic timing unrelated to the wire event.
- Clock-domain ambiguity: “time of processing” is not “time of arrival/departure,” which breaks tight synchronization goals.
C) Practical accuracy ladder (what drives the limits)
As the capture point moves closer to the wire event, software variability is removed—but calibration responsibility increases.
- ~µs: software timestamping (dominant: scheduler/queueing long tails).
- ~100 ns: MAC-level hardware timestamping (dominant: MAC pipeline + clock-domain crossing + residual queueing).
- <10 ns: PHY/Link-layer timestamping (dominant: calibration, asymmetry, and local clock quality).
- sub-ns: typically needs specialized bidirectional calibration or dedicated solutions; only referenced here to set expectations.
D) Scope lock (to avoid cross-page expansion)
Covers: ingress/egress timestamps, event boundaries, timestamp units (TSU/PHC), one-step vs two-step, correction fields, and verification hooks.
Does not cover: full PTP network design, SyncE frequency synchronization, GNSS holdover strategies, or White-Rabbit-style link calibration (use dedicated pages for those).
Next: the minimal PTP message flow required to understand t1–t4 timestamps and how they map to hardware capture points.
PTP Message Flow You Must Know (Only What Affects Timestamps)
For timestamping, IEEE 1588/PTP can be reduced to a minimal set of observables t1–t4 and how those timestamps are carried by Sync / Follow_Up and Delay_Req / Delay_Resp. Everything else is secondary unless it changes where and when timestamps are captured.
A) The four timestamps (t1–t4)
- t1: master egress time for Sync (send event boundary).
- t2: slave ingress time for Sync (receive event boundary).
- t3: slave egress time for Delay_Req (send event boundary).
- t4: master ingress time for Delay_Req (receive event boundary).
B) One-step vs two-step (what changes)
- One-step: the precise t1 is inserted into the Sync packet at the actual egress event boundary.
- Two-step: Sync is sent first; a Follow_Up packet later carries the precise t1, paired by sequence identity.
- When Follow_Up is delayed, lost, or mispaired, the clock servo can show periodic offset “jumps” even if link lock looks normal.
C) correctionField (why it exists)
The correctionField is a controlled accumulation of “known delay” contributed by intermediate devices (for example, transparent clocks), so the endpoints can treat that delay as an explicit term rather than hidden variability.
- Residence time: time spent inside a forwarding device; added when the device can measure it at hardware boundaries.
- Ownership principle: the component that can observe the delay at the correct boundary should own the correction; otherwise it becomes traffic- and temperature-dependent noise.
D) Scope lock (keep it minimal)
Covers: only the message elements required to understand t1–t4, one/two-step delivery, and correction accumulation.
Does not cover: full profile catalogs (Telecom/Power) or complete best-master/announce details; profiles are mentioned only when they constrain timestamp behavior.
Where Timestamps Are Taken: PHY vs MAC vs Switch vs FPGA
Timestamp location is the single biggest lever on achievable accuracy. Moving the capture boundary closer to the wire event reduces software variability, but increases the required calibration burden (fixed delay, asymmetry, clock-domain crossing, and temperature dependence).
A) PHY timestamping (closest to the wire)
- Strength: lowest capture uncertainty because the event boundary is near the physical interface.
- Dominant risks: fixed internal pipeline delay, link-direction asymmetry, and temperature drift; these become the main error terms if not calibrated.
- Verification hook: confirm the reported ingress/egress event aligns with a repeatable physical marker (edge/SFD) and remains stable across traffic load.
B) MAC timestamping (common SoC/NIC balance point)
- Strength: mature ecosystem and straightforward software integration (PHC/driver support is widely available).
- Dominant risks: MAC pipeline placement and clock-domain crossing; “egress timestamp” may occur before or after shaping/queueing depending on implementation.
- Verification hook: check that timestamp statistics are insensitive to host CPU load, and that ingress/egress pairing remains ordered under stress.
C) Switch/bridge timestamping (TC/BC responsibility)
- Strength: enables multi-hop correctness by making intermediate residence time explicit via correction accumulation.
- Dominant risks: mixed networks where some devices do not support transparent clock behavior; hidden queueing becomes unmodelled variability.
- Verification hook: confirm correction terms change predictably with forwarding delay and remain bounded under traffic load.
D) FPGA timestamping (maximum control, maximum responsibility)
- Strength: deterministic pipelines and custom event boundaries; suitable for specialized timing endpoints.
- Dominant risks: reference clock quality, clock-domain crossing discipline, and SerDes/PCS fixed-delay calibration across temperature.
- Verification hook: prove that timestamp counter, event capture, and readout path remain consistent across resets, temperature, and link re-training.
Scope lock
This section compares capture boundaries and their error ownership. It does not expand into SerDes architecture details or full network topology design.
One-Step vs Two-Step: Trade-offs, Failure Modes, and When to Choose
The practical difference is how t1 is delivered. One-step inserts the precise transmit timestamp into the Sync frame at the egress event boundary. Two-step sends Sync first and delivers the precise t1 via Follow_Up, which must be correctly paired and timely enough for stable servo behavior.
A) One-step (in-frame timestamp insertion)
- Requirement: the hardware must insert t1 into the Sync frame at the true egress boundary.
- Risk surface: frame modification implies checksum/FCS handling and strict pipeline placement; a “near-egress” insert point can still be wrong if queueing or shaping sits after it.
- Typical symptom of a bad insert point: a stable but biased offset, or an offset that changes with traffic shaping/load (boundary is not the wire event).
B) Two-step (Sync + Follow_Up pairing)
- Requirement: Follow_Up must carry the precise t1 and be correctly paired to Sync (sequence identity and port identity).
- Failure mode: delayed/lost/mispaired Follow_Up creates inconsistent observations; the servo can show periodic “jumps” even while link lock appears normal.
- First verification hook: measure Follow_Up arrival distribution and pairing continuity; anomalies that match offset “jump” periodicity strongly implicate the two-step path.
C) Selection guidance (interface-agnostic)
- Choose one-step when the platform offers proven in-frame insertion at the true egress boundary and the pipeline is controlled end-to-end.
- Choose two-step when frame modification risk is high or implementation spans multiple blocks; correctness depends on robust pairing and predictable delivery of Follow_Up.
- In both cases, treat the timestamp delivery path as part of the timing loop: capture boundary + ordering + pairing are as important as clock quality.
Scope lock
This section focuses on timestamp delivery mechanics and failure signatures. It does not expand into full PTP daemon configuration catalogs; only timestamp-relevant requirements are stated.
Delay Mechanisms & Correction Fields: E2E vs P2P (Only What Changes the Math)
Delay correction must be treated as a computable and auditable chain. The key decision is whether delay is estimated end-to-end (E2E) using t1–t4, or per-hop (P2P) using neighbor measurements (Pdelay). The correctionField exists to carry delay contributions that endpoints cannot directly observe, so those terms do not turn into hidden variability.
A) E2E: estimate meanPathDelay from t1–t4
- What changes the math: the endpoint uses t1, t2, t3, t4 to compute an estimate of meanPathDelay.
- Best fit: simpler paths where intermediate residence/queueing is either controlled, compensated, or within budget.
- Failure signature: offset/drift that grows with traffic load indicates hidden per-hop queueing is leaking into the estimate as variability.
B) P2P: measure neighbor delay with Pdelay (per hop)
- What changes the math: delay is decomposed into per-hop neighbor terms, improving controllability in multi-switch paths.
- Best fit: complex forwarding scenarios where a single end-to-end estimate would mix many variable contributors.
- Failure signature: one hop shows abnormal neighbor-delay statistics, enabling targeted isolation to a specific segment or device.
C) correctionField: explicit accumulation of non-endpoint terms
correctionField is an auditable container for delay contributions that must be owned by intermediate devices (for example, transparent clocks). Its purpose is to make “unseen delay” explicit so it is not misinterpreted as random noise at the endpoints.
- Residence time: internal forwarding/queueing time added by the forwarding element that can measure it at correct event boundaries.
- Link term (when applicable): per-hop delay terms that are explicitly declared so endpoints avoid double-counting or omission.
D) Ownership rule (prevents double-counting)
The component that can observe a delay term at the correct physical boundary must own it. Otherwise the term becomes load/temperature dependent variability and cannot be reliably corrected.
Scope lock
This section covers only math-relevant objects (meanPathDelay, Pdelay, correctionField) and where each term comes from. It does not expand into full network topology design.
Residence Time, Asymmetry, and Why “Bench OK but Field Fails”
Many field failures are not caused by “PTP instability,” but by delay terms that were treated as constants on the bench. Residence time can change with traffic load and scheduling, and asymmetry can change when media or paths change. When either term moves, offset can jump or drift even if link lock and message rate look normal.
A) Residence time (not a constant)
- Definition: time from ingress event boundary to egress event boundary inside a forwarding device.
- Why TC must own it: endpoints cannot directly observe internal forwarding/queueing, so the term must be measured and declared by the device that can see it.
- Field trigger: traffic load and QoS scheduling widen the residence-time distribution, increasing offset noise and long-tail errors.
B) Asymmetry (Δup ≠ Δdown)
- Definition: uplink and downlink delays are not equal; the bias maps directly into offset.
- Common causes: media/module swaps, PHY path differences, path changes, and environment-induced behavior changes.
- Field signature: replacing a cable/module/switch produces an immediate offset “step” while message rate remains nominal.
C) Practical triage (device-level)
D) Actions that work without “carrier-grade” tooling
- Prefer devices that support P2P and/or transparent clock behavior in multi-switch paths to make residence terms explicit.
- Fix the path and media when validating; then record a baseline of delay/correction statistics for later comparison.
- Treat asymmetry as a budget item; when the environment changes, re-baseline or apply a calibrated fixed term rather than expecting averages to remove it.
Scope lock
This section stays at board/device validation level: residence distribution, asymmetry signatures, and actionable mitigation. It does not expand into operator-scale network engineering.
Clock Recovery / Servo: How Timestamps Become a Disciplined Clock
Timestamps are only measurements until a control loop converts them into a disciplined local clock. The loop typically consumes an offset estimate, a delay estimate, and a rate ratio (frequency error) estimate, then drives a controllable clock element (PHC rate/DCO/PLL) to minimize long-term error while containing short-term noise.
A) Servo inputs (what the loop actually “sees”)
B) Engineering intuition: loop bandwidth is the main knob
The servo behaves like a tracking filter plus an error integrator. Increasing loop bandwidth reduces lock time and improves tracking of frequency drift and path changes, but it also increases noise following and degrades short-term stability. Decreasing bandwidth improves smoothness, but can make the system slow to correct drift and recover from changes.
C) Failure signatures worth logging
- Load correlation: offset noise increases with traffic load → PDV is being followed (bandwidth too wide or delay terms not made explicit).
- Step recovery time: after a path/media change, offset returns slowly → bandwidth too narrow or rateRatio estimator is slow.
- Temperature slope: offset drifts with temperature at constant load → local oscillator drift dominates; ensure the loop can track it.
D) Why hardware timestamps matter to servo design
Hardware timestamping lowers the measurement noise floor at the event boundary. That directly improves the servo’s feasible trade space: either achieve smoother output at the same bandwidth, or increase bandwidth to reduce lock time without pushing output instability beyond budget.
Scope lock
This section focuses on the PTP-driven control loop that disciplines a local clock. It does not expand into SyncE frequency-synchronization systems.
Implementation Patterns: Linux NIC, SoC MAC, PHY TSU, FPGA
Platform selection should be guided by where timestamp truth is created, how it is transported to software/firmware, and how the local timebase is controlled. The same four-layer stack can be used to compare implementations: PTP stack → driver/firmware → timestamp hardware → clock source.
A) Quick map: what usually dominates risk
B) Linux NIC (PHC) — design and validation focus
- Data path: hardware event timestamp → per-direction timestamp queues → driver readout → servo.
- Pitfalls: queue pairing mismatch, sequence association errors, and timestamp point not matching the intended physical boundary.
- Validation hooks: stress CPU/IRQ load; verify timestamp continuity and stable bias across traffic patterns and packet sizes.
C) SoC MAC — where “readout timing” is not “timestamp truth”
- Data path: MAC timestamp capture → DMA descriptor/sideband → interrupt/coalescing → software/firmware.
- Pitfalls: conflating DMA/interrupt delay with the event timestamp; multi-queue behavior changes “when seen” but must not change “what is true.”
- Validation hooks: vary coalescing and traffic; verify timestamp bias does not shift with queue depth or batching.
D) PHY TSU — coherency across clock domains
- Data path: wire-adjacent event boundary → TSU capture → latched register / pin output → host readout.
- Pitfalls: CDC/locking mistakes causing occasional timestamp “jumps” or inconsistent tagging under load.
- Validation hooks: check inter-event interval statistics vs line rate/frame cadence; verify consistent latch semantics under stress.
E) FPGA — calibration ownership is mandatory
- Data path: programmable event tagging → timestamp counter → cross-domain transfer → packet association.
- Pitfalls: fixed delay changes after reset/retraining; missing re-baseline creates offset steps that look like servo issues.
- Validation hooks: power-cycle, reset, retrain, and temperature cycle; verify fixed-delay terms stay stable or are recalibrated back to baseline.
Scope lock
This section is a design-decision and pitfall map. It does not provide platform tutorials or command-by-command procedures.
Accuracy Budget & Measurement: Turning “ns” Claims into Testable Numbers
“Nanosecond-level” only means something when it is expressed as an error budget, measured with a repeatable topology, and verified against well-defined statistics and observation windows. This section decomposes time error into testable contributors and provides measurement patterns that avoid common instrument and boundary traps.
A) Define the measurement boundary first
B) Error budget decomposition (testable entry points)
C) Metrics: RMS + percentile + time-window definition
D) Measurement patterns (repeatable topologies)
E) Pass criteria templates (steady-state + dynamic)
- offset RMS < X ns (X derived from system budget)
- 99.9% < Y ns (tail guard for PDV/load)
- After a defined step (link/master/path change), settle within T seconds
- Settle definition must include a threshold and a hold time (e.g., “RMS < X for N seconds”)
Scope lock
This section does not expand into full phase-noise theory. It provides entry points for mapping clock quality into time-error budget and measurement.
Engineering Checklist (Board/System): Robust, Repeatable, Debuggable
The bring-up path should be a stepwise pipeline where each stage has a measurable probe and an explicit pass criterion. This prevents “it works on the bench” from turning into non-reproducible field failures and supports stable production behavior.
Step 1 — Baseline clock OK
- Check: reference clock integrity, PLL lock behavior, timebase stability under controlled conditions.
- Probe: PHC/TSU clock counters and stability logs with network PDV minimized.
- Pass: stable frequency error and no unexpected timebase steps during warm-up or load changes.
Step 2 — Timestamp path OK (ingress + egress)
- Check: ingress/egress timestamp boundary semantics and queue/sequence pairing consistency.
- Probe: per-direction timestamp continuity, bias stability vs packet size, queue depth, and traffic load.
- Pass: no unexplained bias shifts when coalescing/queues/load change; sequence association remains consistent.
Step 3 — Correction / delay mechanism OK
- Check: whether the path uses E2E or P2P; whether switches behave as TC/BC; whether correction accumulation matches ownership.
- Probe: delay estimates and correction-field behavior when topology or load changes.
- Pass: delay/offset changes are explainable by the configured mechanism; no “silent double counting” of link/residence terms.
Step 4 — Servo tuning OK
- Check: loop bandwidth vs noise following vs lock time; estimator stability under PDV and temperature drift.
- Probe: offset RMS/percentile and rateRatio drift across load/temperature.
- Pass: steady-state RMS and dynamic settle time both meet budget within a defined observation window.
Step 5 — Regression OK (repeatability + debuggability)
- Check: link down/up, master switch, topology changes, and stress conditions (temperature sweep, load sweep).
- Probe: offsets/delays/servo states plus packet loss/reorder markers correlated with temperature and supply.
- Pass: failures are reproducible and attributable to a logged signature (not “rare, untraceable jumps”).
Minimal telemetry schema (log what enables ownership)
Scope lock
The checklist stays focused on timestamp stability and timing debuggability. It does not expand into broad EMI or power-design chapters.
H2-11 · Applications & IC selection notes (PTP HW timestamping)
This section maps interface-scoped needs (HW timestamp location, delay mechanism, device roles, monitoring) to testable selection criteria. It stays inside the timestamp path boundary (no PLL/phase-noise cleaner deep dive).
A) Typical applications (what HW timestamping must guarantee)
- Target: tens of ns class steady-state offset (system budget decides).
- Mechanism: prefer P2P when multiple switches exist and PDV is non-trivial.
- Role mix: endpoints + TC-capable switches to keep correction consistent.
- Target: sub-µs → sub-100 ns depending on motion loop and network depth.
- Mechanism: 802.1AS/gPTP + HW timestamps (TSN scheduling depends on stable time).
- Topologies: line/ring with TC switches; avoid “best-effort” devices in the timing path.
- Target: repeatable time error distribution (RMS + percentile) more important than headline “peak”.
- Need: PPS/trigger outputs (optional) and timestamp event capture for validation.
- Bring-up: verify ingress/egress timestamps match wire events within the platform limit.
- Target: low wander + stable phase steps (avoid periodic “jumps”).
- Key risks: one-step/two-step mismatch, Follow_Up latency spikes, offload paths.
- Selection: prefer well-supported PHC + timestamp queues visible to software.
- Target: deterministic time for sensor fusion and scheduled traffic.
- Common choice: 2-step timestamps with strict sequenceId association and monitoring.
- Requirement: alarms for loss-of-sync, path change, temperature correlation.
Tip: treat “Target” as a budget placeholder. The pass/fail thresholds come from the system-level error budget in the measurement chapter.
B) Selection dimensions (only what touches HW timestamps)
C) Reference material numbers (starting points; verify grade/package/suffix)
These parts are listed to speed up datasheet lookup and lab bring-up. Selection must be driven by the “requirements → capabilities → verification cases” table below.
- Intel Ethernet Controller I210 (e.g., i210-AT): IEEE 1588/802.1AS HW timestamping baseline.
- Intel Ethernet Controller X710 family (platform-dependent driver behaviors; validate one-/two-step).
- Microchip LAN7430 / LAN7431: PCIe-to-Ethernet controller with IEEE 1588-2008 support (one-step/two-step, E2E/P2P stated in datasheet).
- TI DP83630, TI DP83640: IEEE 1588 PTP PHY transceivers (10/100 class).
- TI DP83867, TI DP83869HM: SFD-based timing hooks commonly used with MAC/partner timestamping.
- Microchip LAN8841: Gigabit PHY with IEEE 1588-2008 PTP functions and PTP-related signals.
- NXP TJA1120: automotive 1000BASE-T1 PHY with IEEE 1588v2 / 802.1AS (2-step) timestamping support.
- NXP SJA1105: captures high-resolution timestamps for IEEE 802.1AS and IEEE 1588v2 operation.
- Microchip LAN9374 (LAN9372/3/4 family): hardware time-stamping/time-keeping supporting IEEE 802.1AS (gPTP) and IEEE 1588v2.
- Microchip LAN9668 family: TSN switching devices marketed with IEEE 1588 v2 support (validate the exact timing feature set for the chosen SKU).
Practical rule: if “timestamping exists” but egress timing is unclear (or queue-dependent), force a lab proof: wire-event reference → ingress/egress timestamp distribution → servo residual.
D) Output artifact: Requirements → Capabilities → Verification cases
| Requirement (interface-scoped) | Capability to demand | Verification cases (lab) |
|---|---|---|
| Multi-switch path, stable offset under load (PDV present) |
P2P + TC correction ownership; HW Pdelay timestamps; TC residence measurement.
Example parts: NXP SJA1105, Microchip LAN9374.
|
Load sweep: inject cross traffic, log offset RMS/P99; verify correctionField monotonicity; compare 1-hop vs N-hop residual. |
| Endpoint needs reliable PHC + timestamps (Linux/RT stack) |
PHC device + timestamp queues + clear one-/two-step behavior in driver.
Example parts: Intel I210, Microchip LAN7430/LAN7431.
|
Stress test: packet rate + interrupt coalescing changes; confirm timestamp no-drop/no-reorder; step response settle time vs bandwidth. |
| PHY-level event correlation (closest to wire) |
Defined timestamp point (SFD/PCS), GPIO/event pins (if used), consistent ingress/egress handling.
Example parts: TI DP83630/DP83640, TI DP83867/DP83869HM, Microchip LAN8841, NXP TJA1120.
|
Wire-event reference: compare PHY event pulse / capture vs MAC timestamps; temperature sweep to detect asymmetry drift. |
| Field robustness (alarms + debug hooks) |
Missing-pulse / loss-of-sync indicators, correction anomalies, temperature correlation, counters.
Example parts: TC switches (SJA1105 / LAN9374) + endpoint PHC (I210 / LAN7430).
|
Regression: link flap, path change, load change, temperature sweep; verify alarm triggers + recovery time + no phase “jumps”. |
Deliverable: this table becomes the selection “contract”. Every chosen device must map to a verification case that produces a measurable pass criterion.
Recommended topics you might also need
Request a Quote
H2-12 · FAQs (PTP hardware timestamping)
Each answer is intentionally short and test-oriented. Format is fixed: Likely cause / Quick check / Fix / Pass criteria.
