# Big time providers tech report **URL:** \ **Category:** Server operators\ **Created:** [December 2, 2025, 2:55pm UTC](https://community.ntppool.org/t/big-time-providers-tech-report/4159 "2025-12-02T14:55:30Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![giovane](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/giovane/32/755_2.png) [@giovane](https://community.ntppool.org/u/giovane)\ **Post date:** [December 2, 2025, 2:55pm UTC](https://community.ntppool.org/t/big-time-providers-tech-report/4159/1 "2025-12-02T14:55:30Z")
Folks, We have just released a new [tech report (PDF)](https://www.sidnlabs.nl/downloads/4ZYbgAM6xtydn2DCkwMctt/8e9a3d7793e620ae2096bd24ba173399/BigTime_Characterizing_Large_Time_Service_Providers_tech_report_20251201.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](https://us1.discourse-cdn.com/flex016/uploads/ntppool/original/2X/8/8e407ba1b333889832d7d61b2b5851f0f344d498.png) 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 ---
**Author:** ![Bas](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/bas/32/465_2.png) [@Bas](https://community.ntppool.org/u/Bas)\ **Post date:** [December 2, 2025, 3:15pm UTC](https://community.ntppool.org/t/big-time-providers-tech-report/4159/2 "2025-12-02T15:15:30Z")
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: > **[Time Syncing Software for Ham Radio](https://ve2hew.com/posts/time-sync/)** > > If you want to keep your computer clock perfectly in sync for digital modes like FT8, try these tools for Windows or Linux. Meinberg NTP and Chrony can use data from multiple sources to keep your clock precisely synchronized. > Windows 🖥️ Meinberg NTP... > **[BktTimeSync - BktSoftware](https://www.maniaradio.it/en/bkttimesync.html)** 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. ---
**Author:** ![Badeand](https://avatars.discourse-cdn.com/v4/letter/b/c2a13f/32.png) [@Badeand](https://community.ntppool.org/u/Badeand)\ **Post date:** [December 2, 2025, 8:24pm UTC](https://community.ntppool.org/t/big-time-providers-tech-report/4159/3 "2025-12-02T20:24:56Z")
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. ---
**Author:** ![stevesommars](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/stevesommars/32/2075_2.png) [@stevesommars](https://community.ntppool.org/u/stevesommars)\ **Post date:** [December 3, 2025, 12:16am UTC](https://community.ntppool.org/t/big-time-providers-tech-report/4159/4 "2025-12-03T00:16:40Z")
Nice study! I’ll send comments to the authors off-line. I wrote a [note](https://weberblog.net/azure-ptp-accuracy/) on Microsoft Azure time synchronization. It is surprisingly bad. Some Azure hosts are in the NTP Pool ---
**Author:** ![giovane](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/giovane/32/755_2.png) [@giovane](https://community.ntppool.org/u/giovane)\ **Post date:** [December 3, 2025, 12:06pm UTC](https://community.ntppool.org/t/big-time-providers-tech-report/4159/5 "2025-12-03T12:06:24Z")
thanks for these details, I did not know they were _that bad_. ---
**Author:** ![giovane](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/giovane/32/755_2.png) [@giovane](https://community.ntppool.org/u/giovane)\ **Post date:** [December 3, 2025, 12:07pm UTC](https://community.ntppool.org/t/big-time-providers-tech-report/4159/6 "2025-12-03T12:07:29Z")
thanks a lot, Steve, we will definitely include your post in the report. Nice blog btw, learned a lot form it. ---
**Author:** ![ronv42](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/ronv42/32/1466_2.png) [@ronv42](https://community.ntppool.org/u/ronv42)\ **Post date:** [December 3, 2025, 12:18pm UTC](https://community.ntppool.org/t/big-time-providers-tech-report/4159/7 "2025-12-03T12:18:15Z")
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 ---
**Author:** ![Bas](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/bas/32/465_2.png) [@Bas](https://community.ntppool.org/u/Bas)\ **Post date:** [December 3, 2025, 4:25pm UTC](https://community.ntppool.org/t/big-time-providers-tech-report/4159/8 "2025-12-03T16:25:57Z")
> [@giovane](#): > > thanks for these details, I did not know they were _that bad_. 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: > **[FIX: Windows 10 Not Syncing Time. (Solved)](https://www.wintips.org/fix-windows-10-not-syncing-time-solved/)** > > If Windows 10 not syncing time or displays wrong time, continue reading below to fix the problem. You may have noticed that your computer doesn't sync to the t It’s still a mess. Try that with your 80 old neighbour that just learned using a computer 🤣 ---
**Author:** ![ask](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/ask/32/907_2.png) [@ask](https://community.ntppool.org/u/ask)\ **Post date:** [December 3, 2025, 9:43pm UTC](https://community.ntppool.org/t/big-time-providers-tech-report/4159/9 "2025-12-03T21:43:02Z")
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). ---
**Author:** ![giovane](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/giovane/32/755_2.png) [@giovane](https://community.ntppool.org/u/giovane)\ **Post date:** [December 3, 2025, 10:03pm UTC](https://community.ntppool.org/t/big-time-providers-tech-report/4159/10 "2025-12-03T22:03:49Z")
> 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). ---
**Author:** ![paulgear](https://avatars.discourse-cdn.com/v4/letter/p/ad7895/32.png) [@paulgear](https://community.ntppool.org/u/paulgear)\ **Post date:** [December 6, 2025, 3:30am UTC](https://community.ntppool.org/t/big-time-providers-tech-report/4159/11 "2025-12-06T03:30:28Z")
I performed some tests a while back [comparing AWS & Azure from within their clouds](https://www.libertysys.com.au/2024/03/mister-cloud-part-3/). And then again [on AWS with their new microsecond-accurate time service](https://www.libertysys.com.au/2024/05/aws-microsecond-accurate-time-second-look/). Steve’s data is more up-to-date on Azure than mine, though.