Hacker News Reader

Comment by all_blue_chucks | Hacker News Reader

So why is my Windows 10 clock over a second fast? Isn't NTP accurate to within a fraction of a second?

My windows 10 clock was 2.5 seconds slow! And even after forcing a 'sync now' in the OS time settings and refreshing the webpage a few seconds later, it stayed unchanged. I happened to close and re-open the tab and it showed up correctly (within a few 10 ms) about 10 seconds after the sync.

I can accept that maybe they only sync the time once per day, but what the heck could take so long to have the newly synced time percolate up into the browser? I have a 4 core cpu, 32 gig of ram and a couple-year old ssd, with nothing of consequence running at the time.

NTP performance on the public internet is usually limited by the resources of the server, not the client. Maintaining a large number of NTP sessions is surprisingly performance intensive, which is why many stratum 1 internet NTP servers, time.nist.gov for example, are famously unresponsive. This is also why NTP clients usually take a rather conservative approach by e.g. synchronizing at low intervals during normal operation.

Microsoft operates a generously sized pool of NTP servers to reduce this problem, but since the public Windows time service is not intended to maintain particularly high accuracy it is probably still somewhat limited by server resources. You will see similar issues with the 'open' pool.ntp.org service although lower-stratum pool.ntp.org servers usually seem to have comparatively low load.

Additionally, Windows uses a slight 'variant' of NTP which is intentionally lower precision in public-internet scenarios, likely to reduce the load on the Microsoft NTP service and avoid the issues that some public NTP services have had with e.g. routers using conventional Linux NTP clients absolutely hammering them. The Microsoft docs on this don't give a whole lot detail behind the reasoning and technical details though. Windows NTP achieves much higher accuracy when configured to use a local NTP server.

All of this said, 2.5 seconds is still surprising to me. You might be experiencing rather high local clock drift, although that seems less common since OS timekeeping now relies on the various CPU time counters (which are appreciably more accurate than the BIOS real-time clock), although all bets are off in a VM.

The reason it took some time for the difference to apply to the browser is quite simply the method which the time service actually uses to change the system time. Windows behavior is more or less identical to the Linux nptd/chrony behavior in this case, although the configuration parameters are a little different. When the difference between current system time and NTP time is 'reasonably small', the system synchronizes by 'slewing' the system time by redefining a second to be somewhat shorter or longer for a while. This means that it takes a bit for the clocks to converge, but has the upside of not violating the assumptions that software tends to make about the system clock (e.g. that every second will occur exactly once). On Windows and generally on Linux depending on configuration, very large offsets will result in a 'step' where the system time is just abruptly changed, but this can cause some software to misbehave so is avoided (e.g. cron can act up when a whole minute just never occurs due to a step skipping over it).

Thank you for that detail about how the OS handles the update! It makes sense. It reminds me of the tremendous hoops MS goes through to remain backwards compatible at pretty much all costs.

Last I knew, Windows uses SNTP, not NTP (unless you explicitly install an NTP server or modify the registry to tell it to use NTP).

SNTP is notoriously less accurate but is usually "good enough".

Would like to understand too. On a new android 10 phone it was 1.7 seconds. Not that large, but in computer/processing time it is pretty large.

My iPhone is showing 0.024s for an extra data point.

Phones need to work with the cellular network, so they sync their time with the cellular tower using a GSM protocol (NITZ) and not NTP.

Your phone's settings should have a way to sync with the cellular network (for example, if you set a manual time and then choose set time automatically).

Cell towers (edit: in the USA) are usually within a second of time.gov, so your offset should hopefully be under a second after you sync with the cellular network.

While cellular towers uniformly use a GPS time source for TDMA reasons (which is exactly synchronized to the Naval time minus a known offset), they are surprisingly inconsistent about how time information is delivered to handsets. CDMA requires that towers rebroadcast exactly the GPS time, but GSM generally does not. As a result, GSM handsets may have less accurate time sync depending on how the time service is actually provided.

It's somewhat common for CDMA cellular equipment to be used as a stratum-1 time source in lieu of GPS, since CDMA is easier to receive inside buildings. But GSM is unsuitable for this purpose, and since the long-term prognosis for CDMA seems perhaps less than optimistic, some operators may be forced to run a GPA antenna to the roof.

The windows NTP client is notoriously terrible. It causes issues for the amateur radio mode FT8, for example. The authors suggest installing Meinburg NTP instead.

Reply on news.ycombinator.com