HN Distilled

Essential insights from Hacker News discussions

The Limits of NTP Accuracy on Linux

Original Article

Hacker News Discussion

Here's a summary of the themes from the Hacker News discussion:

Accuracy vs. Consistency in Time Synchronization

A central theme is the distinction between absolute accuracy and relative consistency in time synchronization. While many applications require high accuracy, the ultimate goal for others is simply a consistent timeline across multiple systems for logging and analysis.

  • "Bear in mind that the author specifically reminds us, halfway down, that the goal is consistency, not accuracy per se." - JdeBP
  • "Making all of the systems accurate to GNSS is merely a means of achieving the consistency goal so that event logs from multiple systems can be aligned." - JdeBP

Sources of Jitter and Errors

The discussion extensively covers various sources of time jitter and errors that impact synchronization accuracy and consistency. These range from hardware limitations to operating system behavior and network protocols.

  • "GPS timing modules should have a sawtooth correction value that will tell you the error between the upcoming pulse and GPS time. The issue is that PPS pulse has to be aligned to the receiver's clock. Using that will remove the main source of jitter." - nullc
  • "Aligning the PPS pulse with an asynchronous local clock is going to require a very large number of measurements, or a high resolution timer (e.g. a time to digital converter, tdoa chip, etc. there are a few options.)" - RossBencina
  • "My experience with rt Linux is that it can be exceptionally good at keeping time, if you give up the rest of the multitasking micro sleeping architecture." - azalemeth
  • "For starters, he is comparing times from tsc enabled hardware (x86_i64), with raspberry pi which are arm. Network i/o benchmarking on linux should be done with system calls to the network cards or input devices and not through the kernel drivers etc..." - ainiriand
  • "Well, that TSC-enabled hardware also has other peripherals (like SMBIOS as mentioned in the article) that on the other hand introduce errors into the system." - Avamander
  • "If you do not do this [memory fences], the times will never be consistent. The author produced a faulty benchmark." - ainiriand
  • "It’s wild they talk about the jitter in the pps signals but glossed over the jitter the oscilloscope?" - throwawaysoxjje
  • "Not sure about the Siglent oscilloscope used here, but my old LeCroy WaveAce 2032 (were Siglent had obviously it's hands on) has a trigger jitter of 0.4ns. I'd think the one used here will be of the same order of magnitude, i.e. negligible." - guenthert
  • "But yes, as others have commented already, if only the relative jitter between the signals is of interest, the trigger jitter itself is inconsequential." - guenthert
  • "GPS modules need to be put in a special stationary mode (and ideally measured-in to a location for a day or two) to get accurate timing." - eqvinox

Applications Requiring Precise Timing

The discussion highlights various real-world applications that benefit from or necessitate precise time synchronization, underscoring the practical importance of the technical challenges involved.

  • "What do you need this accurate time for?" was brought up multiple times, leading to several use cases.
  • "Securities regulation?" - mustache_kimono
  • "Say you are running a few geographically apart radio receivers to triangulate signals, you want to have all of them as closely synchronized as possible for better accuracy." - mschuster91
  • "Some major uses of high-precision timing, albeit not with NTP, include: Synchronising cell phone towers, the system partly relies on precise timing to avoid them interfering with one another. Timestamping required by regulators, in industries like high-frequency trading. Certain video production systems, where a ten-parts-per-million framerate error would build up into an unacceptable 1.7 second error over 48 hours. Certain databases (most famously Google Spanner) that use precise timing to ensure events are ordered correctly. As a debugging luxury in distributed systems." - michaelt
  • "Scientific and consistent analysis of streaming realtime sensor data." - aa-jv

GPS, NTP, and PTP: Protocols and Hardware

A significant portion of the conversation revolves around the capabilities and limitations of different time synchronization protocols (NTP, PTP) and hardware (GPS modules, NICs, oscilloscopes).

  • "Only the expensive ones have the correction capability (e.g. uBlox LEA-M8T)" - RossBencina
  • "If you actually care about what time it is you need at least three so you can average them and knock out the error." - ofalkaed
  • "Why is there no mention of PTP here? If you want accurate time synchronisation in a network just use the correct tool, https://en.wikipedia.org/wiki/Precision_Time_Protocol" - diarmuidc
  • "Linux PTP (linuxptp.sourceforge.net) and hardware timestamping in the network card will get you in the sub 100ns range" - diarmuidc
  • "Chrony over NTP is capable of incredible accuracy, as shown in the post. Most users who think they need PTP actually just need Chrony and high quality NICs." - jacob2161
  • "NTP fundamentally cannot reach the same accuracy as PTP because Ethernet switches introduce jitter due to queueing delays and can report that in PTP but not NTP." - eqvinox
  • "chrony can be configured to encapsulate NTP messages in PTP messages (NTP over PTP) in order to get the delay corrections from switches working as one-step PTP transparent clocks." - mlichvar
  • "PTP was based on a broadcast/multicast model to reduce the message rate in order to simplify and reduce the cost of HW support. But that is no longer a concern with modern HW that can timestamp packets at very high rates, so the simpler unicast protocols like NTP and client-server PTP (CSPTP) currently developed by IEEE might be preferable to classic PTP for better security and other advantages." - mlichvar
  • "The Linux PTP stack is great for the price, but as an open source project it's hamstrung by the fact the PTP standard (IEEE1588) is paywalled; and the fact it doesn't work on wifi or usb-ethernet converters (meaning it also doesn't work on laptop docking stations or raspberry pi 3 and earlier)" - michaelt
  • "802.1AS-2020 (gPTP) includes 802.11-2016 (wifi) support." - RossBencina
  • "The biggest limitation is that many ethernet MACs do not support hardware timestamping. Nor do many entry-level ethernet switches." - RossBencina
  • "You're probably looking for https://scottstuff.net/posts/2025/06/10/timing-conclusions/ which discusses the overall conclusions of NTP vs PTP and is the culmination of several blog posts on the topic." - EnnEmmEss
  • "See also https://en.wikipedia.org/wiki/White_Rabbit_Project for this interested in PTP / low latency time sync" - Galanwe
  • "Bare metal code on a dedicated IC or MCU is by definition better than anything running on a general purpose OS on a general purpose CPU. Even if you tune the hell out of it, the latter will have more room for bugs, edge cases, drift, delayed powerup, supply chain idiosyncracies, etc. FYI GNSS processing chips cost $1.30 these days." - contingencies
  • "I'm consistently achieving ca. 10ns of deviation. Hope the author didn't forget this. (But it might also just be crappy GPS modules, I'm using u-blox M8T which are specifically intended for timing.)" - eqvinox

The "Two Watch" Analogy and Confidence in Time

The classic "Segal's Law" regarding having two watches is invoked and humorously extended, illustrating the idea that more synchronized (but potentially conflicting) time sources can paradoxically lead to less certainty, or a need for more sophisticated methods to determine the "true" time.

  • "Segal's Law: 'A man with a watch knows what time it is. A man with two watches is never sure.'" - watersb
  • "A person with two watches finds xyrself suddenly in the messy business of doing full NTP, rather than the much simpler model of SNTP. (-:" - JdeBP
  • "A person with three or more watches knows what time it is in proportion to the square root of the number of watches." - nullc
  • "Sort of. With two watches your confidence is ~1.4 of an arbitrary measurement, with three it is ~1.7, with 4 ~2, etc. Though this is an ever-growing sequence. A better model might be to measure the confidence with something like (x-1)/x as this grows, more slowly with each step, towards 1, without really getting there until infinity. With two watches you are 50% of maximum confidence in your time, with three it is 66%, with four 75%, five->80%, and so on." - dspillett

Technical Critiques of Benchmarking and Implementation

Several commenters provide specific critiques of the technical approach or assumptions made in the discussed article or post, focusing on the validity of benchmarks and the implementation details of time synchronization.

  • "There are so many inaccurate technical details here I wouldn't know where to begin, let alone write a blog post. Sigh." - sugarpimpdorsey
  • "Unfortunately I think the same as you. The provided details in the blog post are by no means any way of doing any sort of time benchmark or network i/o benchmark." - ainiriand
  • "If those times are produced on different architectures, then yes, the comparison can never be accurate enough since the underlying measurement mechanisms differ fundamentally. While the author goes to great lengths to demonstrate very small time differences, I believe the foundation of their comparison is already flawed from the start." - ainiriand
  • "What benchmark? The only numbers he's measuring himself are on the oscilloscope. Everything else is being measured by chrony. Unless you're talking about a different post on the blog?" - Dylan16807
  • "If you're gonna get one [GPS controlled clock], make sure it doesn't hamstring you with wires..." - rkomorn