[ntp:questions] Win7: ntpd adjusting time backwards

Jeroen Mostert jmostert at xs4all.nl
Sun Dec 9 10:17:44 UTC 2012


On 2012-12-09 09:37, David Taylor wrote:
> On 08/12/2012 19:52, Jeroen Mostert wrote:
>> 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?
>
> If NTP is regularly using big steps to adjust the time, it suggests that
> something is wrong. I would take a look at the drift value to see whether the
> clock on your PC has a frequency which is too far in error. You can also enable
> loopstats collection

Drift is currently at -2.3, and no abnormally high/low values have been recorded.

Loopstats collection has been on since the beginning. From the period where 
these big adjustments happen, I get some suspicious data:

56269 38100.218 0.000000000 19.486 0.000000238 0.120120 9
56269 38105.421 -0.054125528 19.486 0.019136264 0.112362 9
56269 38109.421 -0.054433286 19.486 0.017900666 0.105105 9
56269 39160.464 -0.072777326 19.415 0.017956687 0.101492 9
56269 41770.153 0.000000000 19.415 0.000000238 0.094937 9
56269 41775.482 -0.002025903 19.415 0.000716265 0.088805 9
56269 41905.412 -0.044579941 19.409 0.015060036 0.083092 9
56269 43888.511 -0.066275609 19.287 0.016040319 0.088960 9
56269 47068.130 0.000000000 19.287 0.000000238 0.083214 9

The 0 offsets suggest ntpd regularly thinks we're now in perfect sync, something 
which is certainly not true. I don't know how to properly interpret the error 
and stability values.

> and use a tool such as Meinberg's NTP Time Server Monitor or my own NTP
> Plotter to display the results:
>
> http://www.meinbergglobal.com/english/sw/ntp.htm
> http://www.satsignal.eu/software/net.htm#NTPplotter
>
Not to look a gift horse in the mouth, but the fact that your plotter has drag 
and drop for input is annoying. This (to me) is one of the least convenient 
mechanisms for providing input. Since the plotter cannot meaningfully run 
without input, you might as well throw an Open File dialog up when it starts. 
And/or use the Windows convention of supplying a File -> Open menu. I had to 
actually look in the readme to even realize it used drag and drop at all.

The lack of feedback doesn't help either. When I drag peerstats.20121209 it's 
accepted but nothing happens, but it doesn't tell me why not. (Experimentally, 
the reason is that you must drag all files simultaneously, and the set must 
contain loopstats. Dragging peerstats individually never does anything, whether 
before or after it's already seen loopstats.)

As far as the results go, practically all the graphs look crazy, with enormous 
spikes (as you'd imagine). I'll have to do more research before I can 
meaningfully interpret them.

> I would recommend moving to the newer pool directive rather than the older
> multiple pool server lines:
>
> http://www.satsignal.eu/ntp/setup.html#pool
>
> as it may use more pool servers than you would but, more importantly, it reviews
> the servers from time to time and will drop badly performing ones (i.e. broken)
> and replace them with a new one.
>
Thanks. For some reason, none of the documentation I've read even mentions this 
directive, and that includes the setup instructions of the pool.ntp.org website, 
and all manpages for ntpd.conf I've come across. This is the first time I hear 
about it.

> NTP will use interpolation on Windows XP and Windows-8, but normally not in
> Windows Vista or Windows-7. Yes, it can be worth experimenting with these
> settings as you later report.
>
> Does the poll increase from 64 to higher values as NTP runs, or is it stuck on 64?
>
It increases all the way up to 1024.

> 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.
>
Yes, that doesn't appear to be the issue.

> Please let us know how you get on.

The "pool" directive had some effect (I now have 9 servers instead of 4) and 
initially the offset stayed under 10 ms, but it seems that as soon as the poll 
interval goes above 64, the offset starts slipping -- currently at 30 ms. I'll 
keep things under observation; I get the feeling it hasn't quite stabilized yet.

-- 
J.



More information about the questions mailing list