[ntp:questions] Win7: ntpd adjusting time backwards

Jeroen Mostert jmostert at xs4all.nl
Sat Dec 8 19:52:45 UTC 2012


If my event log is to be believed, ntpd is adjusting the clock to times in the 
past (with pretty big intervals):

Log Name:      System
Source:        Microsoft-Windows-Kernel-General
Date:          2012-12-08 15:18:52
Event ID:      1
Task Category: None
Level:         Information
Keywords:      Time
User:          PORTIA\ntp
Computer:      PORTIA
Description:
The system time has changed to ‎2012‎-‎12‎-‎08T14:18:52.347000000Z from 
‎2012‎-‎12‎-‎08T14:18:52.569674500Z.

As I understand it, it's not supposed to be doing this, instead it should slow 
the clock down.

Event log entries from NTP (using the Meinberg install on Win7 64-bit):

ntpd 4.2.6p5 at 1.2349-o Jul 30 11:55:08 (UTC+02:00) 2012  (2)
Raised to realtime priority class
MM timer resolution: 1..1000000 msec, set to 1 msec
Performance counter frequency 3.215 MHz
Clock interrupt period 15.600 msec (startup slew 0.2 usec/period)
Windows clock precision 1.000 msec, min. slew 6.410 ppm/s
using Windows clock directly
proto: precision = 1000.100 usec

This is just a client machine syncing with NTP pool machines, no PPS.

If my Googling indicates anything, those last two lines might indicate a problem 
since NTP is supposed to be using interpolation and it doesn't. There's also 
hints that the crazy huge precision value indicates a problem with a driver. 
However, I've checked two other machines and they log the same thing, so maybe 
this is normal.

I've tried 4.2.7p310 binaries as well, but they log nearly the same thing:

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.3 usec/period)
Performance counter frequency 3.215 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
proto: precision = 1000.000 usec (-10)
proto: fuzz beneath 0.201 usec

The clock is now being adjusted forwards instead of backwards, but still with 
big increments. Current "ntpq -pn" output:

      remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+89.188.26.129   193.79.237.14    2 u   56   64  377   24.989   20.536   8.671
+91.148.192.49   193.67.79.202    2 u   35   64  377   17.968   35.173  13.029
-85.12.35.12     134.221.205.12   2 u   37   64  377   16.989   25.143  10.667
*83.98.155.30    193.79.237.14    2 u   16   64  377   18.963   34.747  13.242

Any hints/tips?

-- 
J.



More information about the questions mailing list