NTP on Windows Vista
June 2008
Well, I thought that the NTP problem was resolved after installing Vista SP1, because the initial trace after the first reboot with full SP1 showed a stable period. The installation of SP1 completed at 0600 UTC yesterday - where the green line is shown:
However, as you can see the oscillations developed once again, and the timekeeping looks no better than before. The drift file does appear to be updating correctly. There is nothing unusual in the NTP event log, just the usual start-up messages about syncing to a couple of modes. The W32time service is disabled, and it does not show as having a PID in the Task Manager.
Any clues about why NTP might be behaving like this would truly be appreciated!
December 2007
I recently installed the Windows port of NTP on to Windows Vista. The initial results were quite disappointing, with wild swings even though the average value was OK. I did not have time to investigate this, but there is no power reduction, speed switching enabled in the BIOS, nor any spread-spectrum functions. I left the PC from Friday last week and, as you can see by the Weekly graph below, it seems that sometime around 2200 UTC last night it suddenly snapped into synchronisation, although there is some evident that is it starting to oscillate once again. There appears to have been a gradual correction over Wednesday to Saturday towards a smaller offset. The same software has been running on that PC continuously. Current data is here. You can see the behaviour of the same hardware (except for a changed hard disk) under Windows XP in the period up to near the end of week 45, when the Windows XP HD failed and I decided to make that PC my Windows Vista test-bed.
Any ideas or suggestions as to what is going on, and as to how NTP could be configured better for that system? It's using UK pool servers, plus on local GPS NTP source which is good to within 20 microseconds.
NTP Events logged
To help resolve this problem, here is a plot of recent performance (ending 09:30 Dec 01) and a section of the Event Log, filtered for NTP events, since the system was rebooted in its final configuration (at about 14:40 on 2007 Nov 29). There are no obvious logged events which would cause NTP problems, although the time step made by NTP does cause logging of both a Kernel and a Security event.
Level Date and Time Source Event ID Task Category Information 30/11/2007 07:10:50 NTP 3 None synchronized to 192.168.0.3, stratum 1 Information 30/11/2007 07:04:11 NTP 3 None synchronized to 195.157.47.129, stratum 3 Information 30/11/2007 07:03:40 NTP 3 None time reset +0.136153 s Information 30/11/2007 01:05:33 NTP 3 None synchronized to 192.168.0.3, stratum 1 Information 30/11/2007 01:04:28 NTP 3 None synchronized to 130.88.200.6, stratum 2 Information 30/11/2007 01:01:23 NTP 3 None synchronized to 212.13.207.101, stratum 2 Information 30/11/2007 01:01:01 NTP 3 None time reset +0.165138 s Information 29/11/2007 18:49:26 NTP 3 None synchronized to 192.168.0.3, stratum 1 Information 29/11/2007 18:48:21 NTP 3 None synchronized to 129.215.160.240, stratum 2 Information 29/11/2007 18:45:13 NTP 3 None synchronized to 212.13.207.101, stratum 2 Information 29/11/2007 18:45:03 NTP 3 None time reset +0.181946 s Information 29/11/2007 14:48:10 NTP 3 None synchronized to 192.168.0.3, stratum 1 Information 29/11/2007 14:44:02 NTP 3 None synchronized to 130.88.200.6, stratum 2 Information 29/11/2007 14:43:53 NTP 3 None frequency initialized -13.085 PPM from C:\Tools\NTP\etc\ntp.drift Information 29/11/2007 14:43:53 NTP 3 None Listening on interface #3 IP Interface 3, 192.168.0.5#123 Enabled Information 29/11/2007 14:43:53 NTP 3 None Listening on interface #2 IP Interface 2, 192.168.238.238#123 Enabled Information 29/11/2007 14:43:53 NTP 3 None Listening on interface #1 Loopback Interface 1, 127.0.0.1#123 Enabled Information 29/11/2007 14:43:53 NTP 3 None Listening on interface #0 wildcard, 0.0.0.0#123 Disabled Information 29/11/2007 14:43:53 NTP 3 None precision = 1.000 usec Information 29/11/2007 14:43:53 NTP 3 None ntpd 4.2.4p3@1.1502-foehr-o Jul 25 12:53:15 (UTC+02:00) 2007 (7)
I'm not sure what to draw from this. I may have restarted NTP at 1448 on Nov 29, to be sure of a known starting condition, and it then synced to the correct server. There are three times when the time was stepped by NTP: 18:45 Nov 29, 01:01 Nov 30, and 07:03 Nov 30. All three resets are positive, and followed by syncing to an Internet server or two, before syncing to the preferred server. The drift file is being updated (judging by both revision date and the contents).
I've tried this both with and without the -M parameter (to enable the multimedia timer) and it doesn't seem to make a difference. The W32Time service is stopped. It doesn't seem to be possible to boot this AMD dual-core system with just one core.Oscillations observed
There was a peculiar spell on December 01 which might provide a clue - it was almost as if NTP was oscillating between two values and trying to correct the median?
An aside - how NTP overcomes the limitation of Windows timer ticks
I extracted the following message from comp.protocols.time.ntp newsgroup, as it sheds light why NTP normally works so well on Windows. I hope Martin will give his permission for these paragraphs to stay. Martin Burnicki wrote:
"In most cases the OS system clock is counting timer ticks to keep the time. When an application reads the system time then a good OS returns the current time with a higher resolution than the timer tick interval, i.e. it returns a time based on the current timer tick count plus the current value of the time counter register which gives an idea whether time is at the beginning or the end of a timer tick interval, and thus is responsible for the resolution of the system clock, depending on the clock rate of that counter.
"The details depend on which time counter register is used for this purpose. If there's just a single register, e.g. in the chipset, then it's pretty easy to deal with it.
"If a CPU register is used to determine the time between 2 timer ticks and you have a SMP or multicore system then you must take care that either the time stamp is always taken from the same CPU/core, or the timers in all CPUs/cores are synchronized to each other so that it doesn't matter which CPU is being read.
"The nanokernel code mentioned by Dave [Mills in the Alpha UNIX implementation] takes care about registers in multiple CPUs, but as its name implies it is some code which needs to run in the kernel to be able to access the registers and provide a proper API to the application.
"If the Microsoft developers would pick up Dave's code and integrate it into the Windows kernel then Windows would probably be a good time keeper as well.
However, Windows does not evaluate the current counter value at all, so the system time is just derived from the number of timer ticks, increases only when a timer tick occurs, and thus the resolution of the clock is limited to the timer tick interval (Vista seems to be slightly different, though).
"Since the Windows kernel source is not available, we can not apply Dave's code to increase the resolution of the Windows system clock since we are unable to modify the timekeeping code in the Windows kernel.
"That's why NTP uses a hack to try to increase the resolution from user space. Of course this is not as reliable and exact as a proper implementation in the kernel could be. However, it's better than just use the resolution provided by Windows. Also, as-is, the interpolated system time is not available to other applications.
"The clock interpolation code for Windows can only use standard API calls, e.g. the PerformanceCounter API. How this API behaves in detail depends on how it is implemented in the HAL. It can either use the CPU's TSC registers, or use any other register which may be available with certain chipsets. This code does not try to synchronize the TSCs on different CPUs, it just tries to run always on the same CPU in order to avoid glitches due to different TSC values on different CPUs.
Martin Burnicki, Meinberg Funkuhren, Bad Pyrmont, Germany"