3 ms·

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

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.

jcrawfordor 7y ago
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).
- allannienhuis 7y ago
  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.

jcrawfordor 7y ago

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).

allannienhuis 7y ago
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.