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
Linux PTP (https://linuxptp.sourceforge.net/) and hardware timestamping in the network card will get you in the sub 100ns range
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.
Chrony is also much better software than any of the PTP daemons I tested a few years ago (for an onboard autonomous vehicle system).
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.
Chrony can do NTP encapsulated inside PTP packets so as to combine the best parts of both protocols
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. The current NTPv5 draft specifies an NTP-specific correction field, which switches could support in future if there was a demand for it.
The switches could also implement a proper HW-timestamping NTP server and client to provide an equivalent to a PTP boundary clock.
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.
On our GCP cloud VMs, cloud-init installs chrony and uninstalls ntp automatically.
PTP is discussed in the concluding article of the series: https://scottstuff.net/posts/2025/06/10/timing-conclusions/
The blog's next post is about PTP, if that's what you're interested in.
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)
This limits people developing/using for fun. And it's the people using it for fun who actually write all the documentation, the 'serious users' at high frequency trading firms and cell phone networks aren't blogging about their exploits.
There's a discussion on that in the comments at the bottom of the article, where the author explains why it wasn't analyzed.
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. 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.)
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. What do you need this accurate time for? I'm equally sure, as acknowledged, the multipath routing isn't helping either.
> What do you need this accurate time for?
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.
In some of these applications you could get away with a precise-but-free-floating time, as you only need things precisely synchronised relative to one another, not globally. But if you're building an entire data centre, a sub-$1000 GPS-controlled clock is barely noticeable.
> But if you're building an entire data centre, a sub-$1000 GPS-controlled clock is barely noticeable.
Dumb personal and useless anecdote: one of those appliances made my life more difficult for months (at a FAANG company that built its own data centers, no less) for the nearly comical reason that we needed to move it but somehow couldn't rewire the GPS antenna, and the delays kept retriggering alerting that we kept disabling until the expecte "it'll be moved by then" time.
So, I guess to make the anecdote more useful: if you're gonna get one, make sure it doesn't hamstring you with wires...
The secret, I'm told, is to make friends with the CCTV/access control team.
They always know the paperwork and contractors needed to get a guy on a cherrypicker drilling holes and installing data cables without upsetting the building owners.
Bear in mind that the author specifically reminds us, halfway down, that the goal is consistency, not accuracy per se. 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.
> What do you need this accurate time for?
Securities regulation?: https://podcasts.apple.com/us/podcast/signals-and-threads/id...
What is the rest of the multitasking micro sleeping architecture, and how do you give it up to improve time keeping?
> What do you need this accurate time for?
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.
Segal's Law:
"A man with a watch knows what time it is. A man with two watches is never sure."
A person with three or more watches knows what time it is in proportion to the square root of the number of watches.
A person with four watches knows what time it is in proportion to 2?
A person with two watches finds xyrself suddenly in the messy business of doing full NTP, rather than the much simpler model of SNTP. (-:
It’s wild they talk about the jitter in the pps signals but glossed over the jitter the oscilloscope?
The scope should be capturing samples from the three channels synchronously.
It appears to be set to trigger on the bottom trace (it appears still) and then retrospectively display the other two.
Given he's using the desktop PPS signal as a trigger reference, and compares the relative times, how would intrinsic scope jitter significantly affect that?
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.
Uh, the Siglent SDS 1204X-E used here has a "new, innovative digital trigger with low latency" ...
There are so many inaccurate technical details here I wouldn't know where to begin, let alone write a blog post. Sigh.
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. 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...
I would be extremely interested in reading your blog post. Fascinating topic.
Saying this is actually the only same thing to do.
I personally will not care for sub 200 microseconds and think it was a good article if read critically. I think it does describe why you should not do that at the moment if you have lots of nodes that need to sync consistently.
Having a shared 10Mhz reference clock is great and that gives you a pretty good consistent beat. I never managed to sync other physical sensors to that so the technical gotchas are too much for me.
There is madness in time.
Edit: changing some orders of magnitude honestly I feel happy if my systems are at 10ms.
In my opinion when you want such precision, you need to stablish strict constraints to the measurements, for example memory fences: https://www.kernel.org/doc/Documentation/memory-barriers.txt
If you do not do this, the times will never be consistent.
The author produced a faulty benchmark.
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?
He uses Chrony, which uses system time, and compares those times across different machines. Unless proper setup is done the benchmark is faulty.
Chrony is what's comparing the times. Zero code written by the author is running except to log the statistics chrony created. Are you accusing chrony of failing at one of its core purposes, comparing clocks between computers? What could the author do differently, assuming the author isn't expected to alter chrony's code?
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. I do not want to generate any polemic sorry!
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.
maybe I missed that, but why not just combine ptp and ntp within chrony, it does support that.
When it comes to realtime guarantees, 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. https://www.lcsc.com/datasheet/C3037611.pdf
See also https://en.m.wikipedia.org/wiki/White_Rabbit_Project for this interested in PTP / low latency time sync