Interesting discussion about #NTP accuracy with GPS as a time source:

Interesting discussion about #NTP accuracy with GPS as a time source:
It is so hilarious to me that we have FOSS maintainers begging for money to try to keep the development of NTP ongoing. NTP - you know, that protocol that the entirety of humanity relies on for access to the internet (or anything on a network for that matter).
Meanwhile the o̶l̶i̶g̶a̶r̶c̶h̶y̶ broligarchy makes billions of the backs of these people.
Anyways, they're currently at $495 of $1000 for their 2025 goal. Go throw them some $ if you feel so inclined.
Linux Time Synchronization: NTP, Chrony and systemd-timesyncd
"The systemd-timesyncd tool provides an NTP client that can synchronize the time on the local host with an NTP server. However, systemd-timesyncd does not provide a server service, so if you need an NTP server on your network, you must use something else, such as Chrony, to act as a server."
Building a more accurate time service at Facebook scale
"In comparing ntpd with chrony, our measurements indicate that chrony is far more precise, which is why we’ve migrated our infra to chrony and launched a public NTP service."
https://engineering.fb.com/2020/03/18/production-engineering/ntp-service/
token - Does the #TOTP Algorithm rely on the client time always being synced correctly? - Information Security Stack Exchange
#ntp
"What happens if for some reason a cell phones clock / calendar is off by a significant amount of time? Does the TOTP (Time-based OTP) algorithm generate an invalid token?
No, not necessarily! Chapter 6 of the RFC recommends a resynchronization, i.e. the clock in the authentication device may drift and the authentication server should remember the clock drift. So over time the authentication device can have a signigicant offset, if the user uses the authentication device regularily. My own project the privacyIDEA authentication system takes care of such a clock drift."
https://security.stackexchange.com/questions/173161/does-the-totp-algorithm-rely-on-the-client-time-always-being-synced-correctly#:~:text=the%20first%20place!-,What%20happens%20if%20for%20some%20reason%20a%20cell%20phones%20clock%20/%20calendar,the%20privacyIDEA%20authentication%20system%20takes%20care%20of%20such%20a%20clock%20drift.,-Also%2C%20do%20time
Petit projet du week-end:
- Un Raspberry Pi et NTPd pour s'ajouter au lu.pool.ntp.org qui manque cruellement de serveurs ... (tout comme la belgique)
Montando um servidor de hora com Chrony e gpsd https://cadu.cc/blog/montando-um-servidor-de-hora-com-chrony-e-gpsd.html
I just spent probably two week to implement a #NTP server as an #unikernel in #OCaml. It was pretty... tuff! My recent outcome is that my "skew" is ~3.5e-7 where chrony has a skew around 1e-6. In other words, the error is overall smaller in my implementation than in chrony's.
I will continue to compare metrics, but it is quite satisfying to confirm the suitability of unikernels for this type of service.
Bei all dem Traurigen und all dem Schmarrn mal was Feines aus der #NASA-"Streichliste": "Nuclear Thermal Propulsion and Nuclear Electric Propulsion are cancelled." Wenn man also vom Einsatz von Kernreaktoren zum Raketenantrieb absieht: Gut so.
Okay, hopefully that's it for #NTP for now:
https://scottstuff.net/posts/2025/05/19/ntp-limits/
I'm seeing up to 200 ns of difference between various GPS devices on my desk (one outlier, should really all be closer to that) plus 200-300 ns of network-induced variability on NTP clients, giving me somewhere between 200 and 500 ns of total error, depending on how I measure it.
So, it's higher than I'd really expected to see when I started, but *well* under my goal of 10 μS.
Huh. Now that I have #otel traces on a bunch of things at home, it's pretty clear that my clocks aren't in sync on every system. They're maybe 1ms off, but it's enough that supposedly-nested trace spans aren't quite nested right.
Which is annoying since I have two local GPS #NTP receivers.
The two "bad" machines were using #systemd-timesyncd to talk to Ubuntu's pool clocks instead of the local clocks. The "good" machines are using #chrony and claim that they're ~2 us off of GPS time.
Now I'm curious -- is this a problem with network latency and Ubuntu's pool, or is that just as good as timesyncd gets?
@mark @M0CUV Perhaps some info here on clocks via GPS, very tantalising rabbit hole....
https://openwrt.org/docs/guide-user/services/ntp/gps
https://github.com/domschl/RaspberryNtpServer
https://github.com/tiagofreire-pt/rpi_uputronics_stratum1_chrony
#gps #stratum1 #ntp #chrony #ntpd
Let's take a moment to remember the guy who made sure we don't have to change Every Goddamn Clock today, David L. Mills, creator of Network Time Protocol (NTP) who passed last year.
My wristwatch is synced to my phone, which is synced to the internet, which knows that time it is right now thanks to David Mills. Cheers to his memory
Just like DNS way, way, waaaaaaaay too many seem to mess up NTP. So I wrote a thing about monitoring NTP with OpenSearch/ElasticSearch.