I noticed Time.is reports synchronization accuracy as ±0.037s on their homepage. Since atomic clocks operate at much higher precision, would this still be considered “atomic accurate” in practice?
Curious to hear thoughts from others who’ve tested public time services!
Even if it is really connected to a ns accurate atomic clock (I suspect this), wider network delay will degrade it’s precision to ms level. So just hype.
That makes sense, network latency by itself would introduce ms-level variation even if the source is precise.
So practically, there’s no way Time.is can claim “atomic accuracy” beyond syncing to an atomic source?
I was testing another system that accounts for network delays differently and it consistently achieves sub 10ms accuracy.
Have you seen any public time services that actually optimize for real world precision rather that just marketing atomic sources?
Part of the problem is the protocol. HTTP(S) was never meant for low latency communication, and trying to measure the latency, it’s just all over the place.
I did play a little around with it:
https://stuff.badeand.net/time/
This server is in the pool. Chrony reports +/- 644us accuracy. Obviously, looking at this webpage, you’re seeing nowhere near this level of accuracy.
1 Like
That makes a lot of sense. From what I’ve seen, even with a precise source like Chrony - 644µs, the moment you serve it over HTTPS, the accuracy drops dramatically.
I was testing a different method, one that optimizes for sub-10ms real-world accuracy despite the protocol limitations.
Have you experimented with any ways to compensate for the network delay issue? Or do you think HTTP(S)-based time services will always be limited by this?
After getting the timestamp from the server, it adds half the round trip time. Don’t know of any other ways of doing it. The way it gets the timestamp from the server is also by requesting /server-time, which serves a binary integer, and has a minimal amount of headers to reduce the transfer time.
PHK wrote some notes on time over HTTPS. I believe his focus was getting enough time sync for security.
There are quite a few network paths with significant asymmetry. 1/2 RTT is a firm limit
1 Like
Oh, there’s a standard like that? Went ahead and implemented it on my server:
curl -I https://stuff.badeand.net/.well-known/time
HTTP/2 204
server: nginx
date: Thu, 13 Feb 2025 17:17:17 GMT
x-httpstime: 1739467037.480
access-control-allow-origin: *
access-control-allow-methods: GET, HEAD
Since the specs clearly states you need permission to use a server for the purpose of time synchronisation using this standard, I hereby grant permission to use my web server (specifically on the stuff.badeand.net subdomain) for this purpose to the members of this forum.
Reminds me of https://uhr.ptb.de/ (or our Dutch version https://klok.sidnlabs.nl:8123/).
I don’t remember if it takes network delays into account though.
Just for the sake of completeness; there is also https://www.vervest.org/htp/
1 Like