The Internet's Time Is Flawed–Why No One Is Talking About It

What Internet applications need an accuracy better than ±50ms?

> time is flawed

you're absolutely correct

Why are people using HTTPS for time? That would be quite the anti-pattern. Standard NTPD port 123 UDP works fine for most people and using Chrony [1][2] one can get down to double digit microseconds or even nanoseconds offset depending on their location. If people need lower than that they should be using their own GPS receivers and local stratum-1 servers in each datacenter and then using Chrony with a short poll interval within the datacenter to the edge stratum-1 servers.

[1] - https://chrony-project.org/examples.html

[2] - https://chrony-project.org/faq.html

> I’ve been researching how online time services sync over HTTPS

HTTPS isn't usually used as far as I'm aware. Wait until you discover that your time server's TLS certificate has "expired" according to your local machine; or hasn't yet become valid (valid in the "future"). Good luck syncing after that!

Most services use some version of NTP; here's NTPv3 spec: https://datatracker.ietf.org/doc/html/rfc1305 but there are others.

> Due to network latency & asymmetry, even widely trusted time sources can drift by ±50ms or more

Yup! Some people would call that a feature to enable leap second smearing.

> most public clocks are way less accurate than we assume

I would bet you're right but I don't recall any studies to measure how bad the problem is. It sounds like you might be barking up somewhere with possibility for unique studies and information!

> Some engineers are experimenting with ways to push accuracy below 10ms

Get rid of HTTP and you can get accuracy below 1ms. HTTP takes up a lot of compute compared to NTP.

Possibly because it's actually just "good enough" for most use cases?

And if you truly require better accuracy, using a GPS units for high acuracy PTP is a thing.

Anyone wanting accurate time is using their own time source (eg GPS) and switches that support distributing it over PTP

First— NTP does not use HTTPS. It uses UDP as a transport since on-time delivery matters more than missed deliveries.

Second— inaccurate time really is only a “problem” if it is not accurate enough. For the purposes of TLS, the current typical time error seems to be well within the tolerance of most communications.

There are plenty of people talking about time synchronization if you know where to look. If you really need something more accurate than NTP, use a PCI card that gathers time from GPS or using a time signal radio broadcast (eg, NIST’s).

This isn't news. Why on earth would anyone think it was better than this?

If you want time more accurate than 50ms, there are tons of options. NTP is not remotely one that any competent scientist or engineer would employ. This is basically the equivalent of saying "I've looked into it, and Toyota Corollas do not have a 0 - 60 time of less than one second." - and that would be the answer to why no one is talking about it.

Who is doing time sync over HTTPS? Is anyone?

For most civilian purposes, time sync is done with NTP, which, using Marzullo's algorithm, can reduce error to around 0.5% of RTT, nothing like "half of RTT". Did you read "0.5%" and thought it meant "50%"?

Is your complaint about something specific? This problem seems imaginary.

> Engineers on NTP forums have confirmed that half of RTT (Round Trip Time) is the firm limit

Which engineers? That statement is not true.

> Some engineers are experimenting with ways to push accuracy below 10ms

Which engineers? NTP accuracy is typically around 0.5ms in good conditions.

The use of the ’ smart apostrophe and the weird 1⃣2⃣ makes me think this post was written by a very confused AI.

In industries like finance each datacenter will have its own GPS receivers with dedicated antennae, and custom timekeeping devices to act as the local stratum-1 servers, and use PTP. Within the DC servers will have very low jitter and high bandwidth network routes to ensure tight accuracy, typically over different networks than the high-traffic connectivity, eg. different interfaces. Where you really really care you can further optimize the OS to ensure tight timekeeping.

Industries that care aren’t sourcing time across residential ISP links and consumer NTP sources. But, for most people it’s accurate enough.

I was told that you shouldn't really count on clock synchronization in distributed systems because it isn't really possible. Einstein says so

https://en.wikipedia.org/wiki/Relativity_of_simultaneity

> This raises some serious questions: 1⃣ How bad is the drift in real-world applications?

Maybe ask yourself how applications that are serious about time deal with sync'ing remote sites. Follow that with how many real world internet applications need those levels of accuracy | correlation over distance.

Two examples at the higher end:

* Multiple Gravity sensors across the globe; these need to filter out passing trucks in some US state that don't also occur at the same time in Australia.

* Square Kilometre Array, with radio astronomy dishes and other sensors on opposite sides of the planet.

Both these projects have additional fun quirks; a signal travelling from (say) the heart of the milky way will encounter sensors on a rotating planet that is sometimes orbiting away from the signal and sometimes towards the signal, depending upon time of year.

Both the projects highlighted have been "in the works" since the 1980s. What are the timing requirements in these? What solutions are in play?

Did you write this with a language model or do you just like emojis, numbered lists, and went out of your way to insert an em-dash?