The Limits of NTP Accuracy on Linux
9 comments
·August 26, 2025azalemeth
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.
JdeBP
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.
mustache_kimono
> What do you need this accurate time for?
Securities regulation?: https://podcasts.apple.com/us/podcast/signals-and-threads/id...
sugarpimpdorsey
There are so many inaccurate technical details here I wouldn't know where to begin, let alone write a blog post. Sigh.
jmpman
I would be extremely interested in reading your blog post. Fascinating topic.
watersb
Segal's Law:
"A man with a watch knows what time it is. A man with two watches is never sure."
JdeBP
A person with two watches finds xyrself suddenly in the messy business of doing full NTP, rather than the much simpler model of SNTP. (-:
nullc
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.
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