The Internet's Time Is Flawed–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.

iOS and MacOS started adding the stupid "smart" apostrophes by default for text input fields all over, including browsers, in some recent update.

OP is also using em-dashes "—" without spaces, just like ChatGPT always does.

Yeah. Between that, the circled numbers, poor spacing, actual use of ±, odd choices of language and the brand new account, I think you're right that it's a bot.

Which ChatGPT likely "always does" because the vast majoity of style manuals prescribe closed usage[1][2][3], and that's therefore how it mostly appears in human-generated text. It's definitely how I learned to use it long before LLMs existed.

[1] https://en.wikipedia.org/wiki/Dash#Spacing_and_substitution

[2] https://www.merriam-webster.com/grammar/em-dash-en-dash-how-...

[3] https://learn.microsoft.com/en-us/style-guide/punctuation/da...

I clicked on their profile to check and saw "Join us for AI Startup School this June 16-17 in San Francisco!" and I thought this was spam but it's actually part of the footer of Hacker News. Hovering over the link, the URL reads "ai-sus".

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).

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

Totally agree. A cheap GPS + Raspberry Pi makes an incredibly capable little NTP server capable of serving 100k clients(after you block the bad actors). The local network is down in the 10s of microseconds. Anything more accurate would need PTO and significantly more investment, but that is more accuracy than I'd ever need.

Absolutely. Additional benefits on RasPi's is the lower power usage which makes the power capacity folks in the datacenter happy. They are also cheap enough every DC can have two of them so that application and system logs do not drift even if there is a prolonged network outage. There are PDU's that can switch between A and B side power for single power supply devices like these.

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.

> 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?

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

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.

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.

> 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.

> 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!

Hilariously, openntpd does it the opposite way, and will go check a HTTPS site to decide what time range might possibly be valid.

https://man.openbsd.org/ntpd.conf#CONSTRAINTS

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?

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

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

CERN, for managing highly-synchronized beam pulses applied km apart from each other: https://white-rabbit.web.cern.ch/

Over the internet? Run a wire

nthing the objection that anyone who needs an accurate clock is getting it via NTP

The question was what internet applications. Not intranet. Also the original article fails to point out that multiple time servers can get you synced quite closely. Also if you do need high precision times you are running your own stratum one time sources on your own network providing your own clocking source with minimal deviations.

So again what internet applications actually care about millisecond or even submillisecond precision?

Ouch: fair enough.

That sounds incredibly unusual albeit highly impressive, just like that homepage!

> time is flawed

you're absolutely correct