There's a discussion on that in the comments at the bottom of the article, where the author explains why it wasn't analyzed.
azalemeth · 1h ago
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 · 1h ago
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.
A person with two watches finds xyrself suddenly in the messy business of doing full NTP, rather than the much simpler model of SNTP. (-:
sugarpimpdorsey · 58m ago
There are so many inaccurate technical details here I wouldn't know where to begin, let alone write a blog post. Sigh.
jmpman · 37m ago
I would be extremely interested in reading your blog post. Fascinating topic.
nullc · 2h ago
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.
Linux PTP (https://linuxptp.sourceforge.net/) and hardware timestamping in the network card will get you in the sub 100ns range
Securities regulation?: https://podcasts.apple.com/us/podcast/signals-and-threads/id...
"A man with a watch knows what time it is. A man with two watches is never sure."
https://en.m.wikipedia.org/wiki/Segal's_law