skip to content

Which of SNTP, NTPv4 or PTP fits each requirement - battery IoT sensors needing seconds, a trading venue's matching engines needing microseconds, a mobile fronthaul needing sub-microsecond phase - and why?

level: seniorimportance: must knowfreq 30%

answer

  1. start from the accuracy budget
  2. where does the error come from
  3. host stack and switch queues
  4. hardware timestamps, on-path support
  5. RFC 5905's own accuracy figures

basics

~20 s

Sensors needing seconds: an SNTP client. Trading engines needing microseconds: PTP with hardware timestamps and PTP-aware switches. Fronthaul needing sub-microsecond phase: PTP with every hop on-path. Full NTPv4 sits between, for servers needing milliseconds to a few hundred microseconds.

solid answer

~50 s

I start from the error budget and where error comes from. **SNTP** — RFC 5905's subset with no filtering, selection or discipline — is enough for battery sensors needing seconds, and polling rarely saves power. **Full NTPv4** is for servers: RFC 5905's own figures put LAN clients within a few hundred microseconds, limited by software timestamps and switch queueing it cannot see. **PTP** (IEEE 1588, not an IETF protocol) removes both: hardware timestamps at the MAC or PHY, and switches that act as boundary or transparent clocks. The trading venue needs PTP with hardware timestamping on the engines, redundant GNSS-fed grandmasters, and monitoring that proves the regulator's UTC limit is met — the limit is the rule's, not the protocol's. The fronthaul needs PTP with full on-path support, because one unaware hop can consume a sub-microsecond budget.

go deeper

for a junior

Recall the ladder: SNTP for simple leaf devices, full NTP for servers, PTP when microseconds or better are required.

for a middle

Explain where each protocol's error comes from - one unfiltered sample, software timestamps and switch queues - and which mechanism removes each.

for a senior

Map each stated requirement to a protocol and name what it costs: PTP-aware switches, hardware timestamping, redundant grandmasters and the monitoring that proves the target was met.

for a principal

Treat time as a tiered service: spend PTP hardware only where the budget demands it, and design the shared GNSS reference, failover and evidence so the tiers cannot drift apart.

## Start from the requirement, not the protocol Time protocols differ by orders of magnitude in what they deliver and in what they cost per device. The design question is always: what accuracy does the application need, against which reference, and what may the solution cost? Three stated requirements show the spread, with full NTPv4 covering the ordinary server estate between them: | Requirement | Fit | Why it fits | What it costs | |---|---|---|---| | Battery IoT sensors, seconds | **SNTP** client, one local server | one sample now and then is ample | almost nothing; no dependants allowed | | Servers and infrastructure, milliseconds | **full NTPv4**, several sources | filtering and selection survive a wrong server | a daemon per host, four or more sources | | Matching engines, microseconds, UTC traceability | **PTP** with hardware timestamps and PTP-aware switches | removes host-stack and queueing error | PTP-capable NICs, switches, grandmasters, monitoring | | Mobile fronthaul, sub-microsecond phase | **PTP** with full on-path support | every hop measured or terminated in hardware | every node on the path PTP-aware | ## What each protocol can deliver - **SNTP** (RFC 5905 Section 14) is NTPv4 without the mitigation algorithms: one server, no clock filter, no source selection, no discipline loop, no dependent clients. Accuracy is whatever one sample gives, decaying with oscillator drift until the next. - **NTPv4** (RFC 5905) states its own typical figures: primary servers within a few tens of microseconds, secondary servers and clients on fast LANs within a few hundred microseconds, and within a few tens of milliseconds with poll intervals up to 36 hours. What limits it is mostly where timestamps are taken — in software, after system calls and queues — and queueing in switches that differs by direction. - **PTP** is defined by IEEE 1588, not by the IETF; RFC 8173 and RFC 8575 model its data sets as a MIB and a YANG module. RFC 8173 summarises it as supporting synchronization accuracy "in the sub-microsecond range". It gets there by **hardware timestamping** at the MAC or PHY, the most accurate of the four capture points RFC 9769 lists, and by making switches part of the protocol as **boundary clocks** or **transparent clocks**. ## The trading venue Matching-engine timestamps must be comparable across hosts to microseconds, and a regulator may set a maximum divergence from UTC. Separate the two sources of the number: the limit and the evidence it demands come from the rule; the protocol only delivers time. A design that meets it: 1. **Grandmasters locked to GNSS**, more than one, so PTP's best master clock algorithm can fail over. 2. **PTP-aware switching** — boundary or transparent clocks — on every path from grandmaster to engine. 3. **Hardware timestamping** on the engines' network interfaces, so host-stack latency never enters the measurement. 4. **Monitoring** of each host's offset, an alarm at a margin below the limit, and retained records proving traceability. NTPv4 with software timestamps, at a few hundred microseconds on a LAN by its own RFC's account, leaves no margin. NTP with hardware timestamps and the RFC 9769 interleaved modes narrows the gap and makes a reasonable independent cross-check, but NTPv4 cannot measure the time a packet sat in a switch queue. ## The mobile fronthaul Radio sites need their phase aligned with each other, not just a fair idea of UTC, and the budget is sub-microsecond end to end. Every PTP-unaware hop adds queueing variation that no endpoint can measure, so the design puts every node on the path under PTP — a telecom PTP profile with full on-path support is the usual choice — with hardware timestamping throughout. NTP is not designed for this budget. ## The battery sensors A sensor that needs seconds gains nothing from PTP or a continuously running discipline loop and pays for both in power and hardware. An SNTP client that wakes, queries one local server and sleeps meets the requirement. Securing that exchange, for example with Network Time Security, is a separate decision owned by the authentication question. ## Costs that decide the edge cases - **One unaware switch** on a PTP path can dominate the error budget; PTP's accuracy is a property of the whole path, not of the protocol alone. - **Path asymmetry** — different fibre lengths or queueing in each direction — is invisible to both protocols' offset calculation and must be measured and compensated. - **Security.** RFC 7384 notes that IEEE 1588-2008 offered only an experimental security annex that was never formalised, and that PTP has widely been deployed unsecured; a rogue master can win the best master clock algorithm. - **Coexistence.** The same GNSS-fed reference can feed PTP for the engines and NTP servers for the rest of the estate.

  • Could NTPv4 meet the trading requirement if every host had hardware timestamping?
    It would narrow the gap: RFC 9769 interleaved modes let a server deliver its hardware transmit timestamp, removing host-stack error. What remains is queueing inside switches, which NTPv4 cannot measure; PTP's boundary and transparent clocks remove it. Hardware-timestamped NTP makes a good independent check, but a microsecond target with margin still points to PTP with on-path support.
  • Why not run PTP on the battery sensors too, for uniformity?
    PTP's accuracy rests on hardware timestamping in the device and PTP-aware switches on the path, and it exchanges timing messages continuously. A sensor that needs seconds would pay in hardware and power for accuracy it never uses, while an SNTP client polling one server occasionally meets the requirement.
  • What does the trading design need beyond the protocol to satisfy a regulator?
    Evidence. A documented chain from UTC to each timestamping host — GNSS-fed grandmasters with a holdover plan — continuous monitoring of each clock's offset, alarms at a margin below the limit, and retained records. The protocol delivers time; proving it was within the limit is an operations deliverable.

saying these in an interview costs you the question

  • NTP reaches microsecond accuracy if you simply poll more often.
  • PTP's accuracy comes from the protocol alone, so ordinary switches are fine.
  • Every device should run the most accurate protocol available.
  • Choosing PTP satisfies a regulatory UTC limit without any monitoring.
  • SNTP is just an older name for NTP and suits servers equally well.