Does Windows (7+) NTP time sync actually work? - Page 1
Forum section: electronics / general

author: peter-h
author_rank: Super Contributor
timestamp: November 12, 2024, 07:05:05 pm
content: I am testing a GPS-NTP product but this issue is found with any of the NTP time sources which can be configured under Control Panel / Date & Time. Basically the PC time differs by 1 to 1.5 seconds - occassionally much less - from the "proper time" as shown by say time.isAIUI, NTP should sync the PC's RTC "exactly" but instead is seems to randomly gain, sometimes lose, a second. Is the MS code just crap because the PC RTC (based on the original 1980s Hitachi 6818 - can't find the data sheet on it now) holds only seconds, so there is no "trivial" way to load it accurately from a seconds+milliseconds value obtained via NTP? Obviously one could do it by taking the NTP time, say 30.345 secs, and wait for 655 milliseconds and then load 31.000 into the RTC.

author: Monkeh
author_rank: Super Contributor
timestamp: November 12, 2024, 07:38:01 pm
content: Yes, it works exactly as well as a daily sync can be expected to. Mine, for example, last synced at 0322, so is now 1.3 seconds off. When running your PC entirely ignores the RTC (which is much more stable than this), all timekeeping is done essentially in software, and is subject to substantial drift over time.If you want a Windows system to maintain time accurately you'll need to install a suitable service to perform continual adjustment. Windows does provide one, normally only activated when connected to a domain, and I've never bothered to dig into configuring it. Personally, I'd suggest just good old fashioned 'ntpd':https://www.meinbergglobal.com/english/sw/ntp.htm

author: peter-h
author_rank: Super Contributor
timestamp: November 12, 2024, 08:31:21 pm
content: We may have wires crossed.WinXX workstation syncs once a week. So with a 20ppm xtal it can be 11 seconds off. One can edit the registry entry (followed by a reboot!) to say 100 secs (I believe, the default for winXX Server) but you see the same error.Now I can well believe that Windows does not read the RTC except when it boots up, and normally it counts time with a 1ms interrupt. But then what does the time sync actually do? It should set the RTCandset its internal ms count. But let's say the RTC setting is only +/- 1 sec; the 1ms based clock should be settable to the nearest 1ms and then going to e.g. time.is should show that. Unless time.is use client javascript to read the RTC...What does the above NTP package actually do? It doesn't actually say. At least, it must fix up the 1ms clock. But why doesn't the Winxx NTP service do that?I tried to install it but failed; don't really understand what it is trying to do. It was asking for firewall modifications but they should already be in place for the Windows NTP process. I installed it but could not find anything under Services afterwards. So I uninstalled it.

author: Monkeh
author_rank: Super Contributor
timestamp: November 12, 2024, 08:56:01 pm
content: If you perform a manual sync, your time should then be exactly right. Mine certainly is (okay.. it's slipped 100ms or so since I synced it..). How Windows handles the RTC I don't know - usual practice in an OS is not to mess with it except maybe to set it to the nearest second on shutdown.ntpd will continuously monitor your chosen servers and sync the current clock much more precisely than any 24h+ interval. The Windows service doesn't do that because they don't want to maintain the infrastructure to supply NTP to billions of machines - if you set up a domain, the domain controller will become an NTP server and joined machines will be configured to maintain their clocks properly.

author: peter-h
author_rank: Super Contributor
timestamp: November 12, 2024, 09:01:34 pm
content: OK; posts crossed.I have been doing manual sync herebut it seems to have no effect.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 12, 2024, 09:56:19 pm
content: There is essentially no guarantee, from what I get, on Windows < 10. So 1 s of error looks pretty, uh, good in that context.You can read this:https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/support-boundary-high-accuracy-time

author: radar_macgyver
author_rank: Frequent Contributor
timestamp: November 12, 2024, 10:04:01 pm
content: Windows does not implement true NTP - it queries an ntp server at some period (I thought it was once a day) and sets its internal clock based on that by stepping the clock forward or back. This referred to as "SNTP" - the equivalent of running 'ntpdate' on a Linux box. True NTP continuously monitors the clock drift of local time and adjusts the clock rate rather than stepping the time. Thus, time remains monotonic, unless there's a large difference between network time and local time.Windows' internal timekeeping seems to rely on the CPU performance counters (based on a quick google search) so like Linux it only uses the RTC to set the initial time at boot.

author: peter-h
author_rank: Super Contributor
timestamp: November 12, 2024, 10:07:29 pm
content: QuoteOK. But this is amazingly crap, to have NTP client and it being like this. NTP does a complex duplex algorithm to do it within maybe 10ms (over the internet).The reason that other client (above) failed to do anything could be because it needs MS VC++ redistributables... well, I've already spent enough time on that stuff for past (and actually important) programsFrom the MS linkTighter accuracy requirements were outside of the design specification of the Windows Time Service on these operating systems and isn't supported.So I will try win10 and report.QuoteThat sounds about rightUPDATE: Win10 is same as win7. After sync using any of the three NTP sources I have (one of which is my GPS-source one) I see it 0.6 secs ahead.

author: Peabody
author_rank: Super Contributor
timestamp: November 12, 2024, 10:24:44 pm
content: I think Windows does not update its clock to the NTP value all at once, but instead gradually updates over some period of time. Apparently there's some risk of breaking things if too big an adjustment (seconds) is made.You might look into NetTime as a replacement for the Windows time function.

author: peter-h
author_rank: Super Contributor
timestamp: November 12, 2024, 10:39:05 pm
content: It is certainly true that you want to maintain monotonicity at the whole-seconds level, which I believe is the file timestamp resolution.I now have two machines here, win7 and win10, 0.6 secs fast an 1.4 secs fast respectively, and will see tomorrow if that error has  reduced.EDIT: yes both are gradually drifting down. About 100ms per hour.UPDATE: after 7hrs, the win7-64 machine is at +1.1secs while the win10 one drifted down to 50ms.So Peabody above is right, but the implementation varies. I did a bit of a google and it is clear that it varies across Windows versions and across other stuff. Also the windoze workstation default period of 1 week is useless because the RTC will drift loads in one week. I've set mine to 100 secs and probably 1000 secs is about right if you want yours to be 1-2 secs out.But to test my GPS-NTP I just need one machine to work, which I have.

author: gmb42
author_rank: Frequent Contributor
timestamp: November 13, 2024, 11:19:23 am
content: Generally, Windows uses thew32tmservice for clock sync. Older systems don't need to keep time with high precision, but more recent (and supported) systems do have the option ofhigh-accuracytime sync.If the device is a member of a domain, then the domain controllers are the sync source and they must be set to obtain time from a reliable source. For standalone machines, w32tm can be set to different time sources.I haven't used NTP on Windows for some time, but there is an ntpd implementation for Windows, e.g.herethat should be a little more accurate than w32tm.

author: peter-h
author_rank: Super Contributor
timestamp: November 13, 2024, 01:10:12 pm
content: Interesting. The w32tm description says nothing about the parameters for thegradualtime adjustment we are seeing.One thing seems sure: the 6816 RTC is not used for the time reference. It probably just gets set at shutdown, and read at startup. Maybe it gets loaded during runtime; obviously it would make sense to load it during NTP syncs, or whenever the user sets the time manually.

author: gmb42
author_rank: Frequent Contributor
timestamp: November 13, 2024, 04:47:15 pm
content: Doing the searching work for you, the w32tmhow it workspage has a lot of info.TL;DR; unless the time discrepancy is large, the w32tm service will skew clock adjustments. If the discrepancy is large, the clock will jump.

author: David Hess
author_rank: Super Contributor
timestamp: November 13, 2024, 05:41:51 pm
content: The documentation for the program Tardis 2000 had a good description of how the PC and Windows time service works. I think this program will works on Windows 10 and does what you want.

author: srb1954
author_rank: Super Contributor
timestamp: November 13, 2024, 08:36:02 pm
content: Quote from: peter-h on November 12, 2024, 07:05:05 pmThe original PC RTC chip was a Motorola MC146818, the datasheet for which is still available from the NXP web site.The Hitachi 6818 was a later second source.

author: peter-h
author_rank: Super Contributor
timestamp: November 14, 2024, 02:27:27 pm
content: The win10 laptop is still "exact" while two win7-64 PCs have drifted slowly down to 1.0 and 0.5 secs. Evidently on win7 the drift is very slow; of the order of 300ms per day.Yes indeed the 6818 counts whole seconds only so no way to set it to anything more precise. It also cannot, when with a 32768Hz xtal, do a 1ms interrupt, so the PC must be using some hardware timer for that.QuoteYes, although the followingQuotedoesn't say how it varies across windows versions etc.Fundamentally there must be some sort of "control loop", with the NTP time as the "setpoint", the current time as the "process variable", although probably not the classic PID algorithm, and the loop constants vary in various mysterious ways. I reckon win7 uses a very low proportional gain, and it doesn't look like there is any integral term on win7 (because that ends up with a long term error of around 1 sec) but there is both a larger proportional gain and an integral term on win10 (because that zooms down to a "zero" error over a day).Any NTP sync approach which desires to maintain monotonic time must be doing something like this.EDIT: The time on win7-64 never does reach zero error. It remains in the 0.8-1.5 sec error area, even after weeks.