[ntp:questions] Win7: ntpd adjusting time backwards

Jeroen Mostert jmostert at xs4all.nl
Sun Dec 9 14:16:46 UTC 2012


On 2012-12-09 09:37, David Taylor wrote:
> I have seen one issue on Windows-7 where, at boot-up, NTP makes the wrong choice
> about interpolation because the system clock at that time is running at 15.6 ms,
> whereas it will later switch to 1 ms (I may have the explanation slightly
> wrong). For this reason, on both my Windows-7 LAN-synced PCs I have:
>
> NTPD_USE_SYSTEM_CLOCK=1
>
> But I do then see: "using Windows clock directly" in the NTP events.
>
For what it's worth, after a reboot (with all custom overrides removed), I saw 
exactly the behavior you describe. And this is after the system is already up 
and running, starting ntpd manually. ntpd logs this:

   ntpd 4.2.7p310-o Oct 09 17:56:01.10 (UTC-00:00) 2012  (1): Starting
   Raised to realtime priority class
   Clock interrupt period 15.600 msec
   Performance counter frequency 14.318 MHz
   MM timer resolution: 1..1000000 msec, set to 1 msec
   Windows clock precision 15.600 msec, min. slew 6.410 ppm/s
   HZ 64.102 using 43 msec timer 23.256 Hz 64 deep

Even though the multimedia timer has been set to 1 msec, 
GetSystemTimeAsFileTime() is still returning timestamps with a 15.6 msec offset. 
This should be 1 msec. Running clockres (from SysInternals) gives back that the 
timer interval is indeed 1 msec. Restarting NTP:

   ntpd 4.2.7p310-o Oct 09 17:56:01.10 (UTC-00:00) 2012  (1): Starting
   Raised to realtime priority class
   Clock interrupt period 15.600 msec (startup slew -0.1 usec/period)
   Performance counter frequency 14.318 MHz
   MM timer resolution: 1..1000000 msec, set to 1 msec
   Windows clock precision 1.000 msec, min. slew 6.410 ppm/s
   using Windows clock directly

I'm not sure what the issue is, here. Either ntpd somehow fails to set the 
multimedia timer (unlikely), or there is a delay between the multimedia timer 
getting set and the resolution increase in GetSystemTimeAsFileTime(), or (worst) 
GetSystemTimeAsFileTime() actually can't make up its mind. I'd need to whip up 
some code to test this. If it's due to a (subsecond) delay, it would be trivial 
to fix this in ntpd.

-- 
J.



More information about the questions mailing list