Giovane, thanks for sharing this. Interesting material and concerning to see that MacOS and Windows are so vulnerable…
The reference section als contained some interesting references to earlier studies.
Especially the Deep Dive on the NTP Pool! This might add some valuable insight about underserved zones.
Especially one of the assumptions by pool operators about helping underserved zones by other (more distant pool servers) is addressed. This assumption is that because of physical distance between a pool server and client(zone) it makes no sense to add pool servers from zones not physically adjacent to the clientzone. The conclusions of this deep dive support the idea that it might make sense to add servers from a more distant zone while still providing a solid NTP service.
Just a small correction about chrony. It doesn’t ignore KoD RATE responses - it temporarily reduces the polling rate. Not a huge difference to not supporting it at all, but it is supported.
The average polling rate depends on the network conditions and clock stability. It should be within the configured minpoll and maxpoll. Typically it should be able to reach the default maxpoll of 10. With the polltarget option it is possible to force chrony to quickly reach and stay at maxpoll, if the server load needs to be reduced as much as possible without increasing minpoll.
Meinberg have recently finally updated their build of ntpd classic for Windows, so that could be an option to address some of the issues with Windows’ native NTP time sync.
On a related note, I had understood that more recent versions of Windows (since Windows 10/Windows Server 2016) support “high accuracy” time sync, and while I don’t find the reference anymore right now, I had gathered that that would be built around a (full) NTP client, rather than an SNTP client.
Do your findings mean that even in this “high accuracy” mode, it still is “only” an SNTP client after all?
Or is it that the default (which I think is what you focused on) is SNTP, and (full) NTP requires some explicit configuration?
(I understand explicit configuration will definitely be needed for the Windows versions were this was first introduced, i.e., Windows 10/Windows Server 2016), but I had gathered that this new mode would be the default in then later versions, but I think it was never said explicitly, so maybe my understanding/interpretation was wrong?)
Interesting material and concerning to see that MacOS and Windows are so vulnerable…
we were equally surprised by these results.. I mean, these are gigantic vendors with no excuses to run such service.
I do hope that Ubuntu switch to chrony with NTS by default encourage MS and Apple to fix their clients and use NTS
Especially the Deep Dive on the NTP Pool! This might add some valuable insight about underserved zones.
Oh yeah, we looked into that a couple of years ago. We posted it here and I remember that @ask said he planned to phase out country zones if memory serves me well. Have a look in this thread here
Just a small correction about chrony. It doesn’t ignore KoD RATE responses - it temporarily reduces the polling rate. Not a huge difference to not supporting it at all, but it is supported.
Thanks @mlichvar, we will add this to the tech report and udpate it
We sort of did not touch the default config files --except for setting which NTP servers to use.
Do your findings mean that even in this “high accuracy” mode, it still is “only” an SNTP client after all?
So I don’t think we find any ``high accuracy’ ’ mode. The other modes of Windows we found are on appendix B – as a standalone system and part of an AD
Bear in mind that the USNO event of 2012 (where it set clocks 10 years back in time) wrecked havoc in many Active directly servers at the time. Oddly enough, MS sets the panic mode (how much you can shift clocks) by 2 weeks, so anything within this period can be shifted.
