Big time providers tech report

Server operators
1

Folks,

We have just released a new tech report (PDF) on analyzing other time services providers than the NTP Pool.

Why does this matter?

There’s been plenty of academic papers bashing the NTP Pool – and yet, there has been few analyzing other time service providers. Like, MS, Apple, and Google all set their billions of devices to use their time services:

image
image566×293 49.4 KB

So what we did:

  • We look at how big their time services are
  • How they map clients to NTP Servers (Surprise: 4 do something similar to GeoDNS)
  • We compare their networks to the Root DNS systems in terms of replication
  • We find that Microsoft servers 50% of our clients (4.5 thousand) with a single time server (IP address) violating RFC8633
  • We compare the accuracy of these times services using two VPs with have GNSS and atomic holdovers – most of them are OK, but we see that Microsoft for a period of time perform poorly compared to the others – they were out of sync
  • Microsoft still uses NTPv3, and only Cloudflare and Ubuntu support NTS

There’s more to it, and feedback is more than welcome

Thanks

6 Likes
2

Did you know that Windows is so poor at time-keeping even with the ntp-time from Microsoft, or any other for that matter.
That most Ham-radio operators install a separate program to set windows time correct and it will start drifting again in minutes. Going waaaaaaay of in the distance.

No matter what you do in the registry or what timeserver you give, it often takes a week to contact their NTP-server to set the computer right.

Have a look:

Microsoft may have timeservers, but their OS isn’t able to use them properly or maintain a fairly stable clock.

I often get mailed by other Ham radio operators why their Digital modes won’t receive anything.
Why they can’t decode signals.

When I tell them to check their clock in Windows and that it needs to be accurate up to about <2 seconds.
They often tell me their clock is minutes to sometimes hours wrong!

Why haven’t they fixed it yet with a proper client? Reminds me of they’re calculator that couldn’t deduct for decades.

Bashing the pool is one thing, but another is your OS can’t keep time because of a broken/bad NTP-client in itself.

My 2 cents.

3

Windows, by default, is configured as an SNTP client, only checking the time every couple days or so. It can, however, be configured to synchronise much more aggressively and with several sources.

1 Like
4

Nice study! I’ll send comments to the authors off-line.

I wrote a note on Microsoft Azure time synchronization. It is surprisingly bad.
Some Azure hosts are in the NTP Pool

4 Likes
5

thanks for these details, I did not know they were that bad.

6

thanks a lot, Steve, we will definitely include your post in the report.
Nice blog btw, learned a lot form it.

7

When you only check time say every two days you are going to be hit with a drift and if your mother board clock is off when you boot and say the boot doesn’t check time you will see that offset also. Microsoft needs to switch to a more active mode when it come to time by default

8

Yes they are. It’s sometimes so bad that it won’t synch the clock at all, then you have to set it by hand first in order to get it going again.

Read and laugh very loud:

It’s still a mess. Try that with your 80 old neighbour that just learned using a computer :rofl:

9

Testing from a single vantage point is a curious choice (from the chart of absolute offset data). Really anything outside Holland (in this case) is irrelevant data as users elsewhere would be served from another server (in the anycast case) or network path (in the unicast case).

1 Like
10

Testing from a single vantage point is a curious choice (from the chart of absolute offset data).

Well, we did two in fact. We did also AWS-Stockholm, as it has PTP services.

I agree it is not ideal, but we really wanted “ground truth” to be sure. We could still do other VMs in other cloud regions, but we obviously will have cloud bias, so that’s why we did at SIDN which is small company.

Really anything outside Holland (in this case) is irrelevant data as users elsewhere would be served from another server (in the anycast case) or network path (in the unicast case).

If by irrelevant you mean “it is not data from the server that would likely server the client” , you may be right.

For anycast services (Google, Cloudflare, and Meta), our two VPs reach only two locations – and we have no idea which. For unicast services, we could have excluded all other IPs that would not be used – but we decided to keep it and surprisingly, most of them still delivery quite good accurary.

So there’s value in the extra data – we can still zoom in on the unicast IP addresses that would have been used by those PTP Vps, but it’s a subset of the data.

And we disclaim this in the paper – the anycast part.

Limitations: Our experiment has two limitations. First,
our VPs can reach only a single site (location) of anycast
providers (Google, Cloudflare, and Meta) , assuming routing
does not change during the measurements [86]. Therefore,
we can only partially evaluate these services’ accuracy. (For
non-anycast services, we measure all locations by measuring
all IP addresses).

1 Like
11

I performed some tests a while back comparing AWS & Azure from within their clouds. And then again on AWS with their new microsecond-accurate time service.

Steve’s data is more up-to-date on Azure than mine, though.

2 Likes