|
|
Windows 8 to 8.1 and other upgradesIt's possible that if you are using the serialpps.sys mentioned below with the kernel-mode PPS handling, that when Windows is updated, either through a routine monthly update or a more major version upgrade such as 8.0 to 8.1, that your careful changes to the system will be reverted back to a standard Windows driver. The symptom of this would be that the offset and jitter become much worse, and that the "o" tally code line in the output of ntpq -pn disappears. With serialpps.sys C:\>ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
o127.127.22.1 .PPS. 0 l 3 16 377 0.000 -0.028 0.020
+127.127.20.1 .NMEA. 0 l 2 16 377 0.000 -0.047 0.024
*192.168.0.3 .PPS. 1 u 33 32 377 0.193 -0.069 0.104
-192.168.0.4 .PPS. 1 u 18 32 377 3.123 0.100 0.151
Without serialpps.sys C:\>ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
+127.127.20.1 .NMEA. 0 l 2 16 377 0.000 -0.047 0.024
*192.168.0.3 .PPS. 1 u 33 32 377 0.193 -0.069 0.104
-192.168.0.4 .PPS. 1 u 18 32 377 3.123 0.100 0.151
Another way to check may to use the Device Manager to check the driver chain for the COM port you are using, and see whether serialpps.sys is listed in the driver chain. In File Explorer (a.k.a Windows Explorer), right-click Computer, and select Manage. Click on the Device Manager, expand Ports, right-click, Properties on the COM port you are using. On the Driver tab, click Driver Details, and look for serialpps.sys in the list. Here's what I see on one Windows-7/64 system:
The cure is simple, re-install the serialpp.sys driver. For non-standard COM ports, or if you encounter other problems, try the loopback-ppsapi-provider instead.
NTP on 64-bit Windows-7 with GPS/PPSSigned kernel-mode driver availableThere is no longer any need to go through the magic hoop described below to get Windows-64 to accept unsigned drivers. You can download the package from here: http://people.ntp.org/burnicki/windows/serialpps-20120321-signed.zip My thanks to Martin Burnicki of Meinberg for making this available. Using a kernel-mode driverFollowing a request for testing from Dave Hart, I recently (2011 Mar 17) managed to get NTP working on a 64-bit Windows-7, SP1 system using Dave's modified serial driver even though that driver is unsigned and not normally allowed on 64-bit Windows.
As I am using a Sure Electronics GPS board (which runs at 9600 baud and has $GPGGA as the first sentence), my ntp.conf file has lines like: # ref-clock drivers server 127.127.22.1 minpoll 4 # PPS - serialpps.sys, port COM1 server 127.127.20.1 minpoll 4 mode 18 prefer # NMEA serial port, 16 = 9600 baud, 2 = $GPGGA # Other servers server 0.uk.pool.ntp.org minpoll 10 server 1.uk.pool.ntp.org minpoll 10 server 0.nl.pool.ntp.org minpoll 10 server 1.nl.pool.ntp.org minpoll 10 How well does it work?Here are the rather dramatic results! First, a plot of offset as seen by MRTG. Variations of up to 2ms or more with the LAN sync, variations of something less than a millisecond with the kernel-mode PPS sync after 07:30, and finally offsets around 50 microseconds with the interpolation - looking almost like noise on the MRTG plot, after 15:30.
I did wonder about the almost sinusoidal nature of the offset with the PPS and kernel-mode driver, and closer investigation showed that the offset had a period of about 1.62 minutes (about 97.2 seconds), and as MRTG samples only every five minutes this as aliased into a near hourly period on the MRTG plot. The jitter as reported by NTPD in the loopstats data shows an equally dramatic improvement. Using a basic LAN sync, but with a very tight coupling between the PC and an excellent stratum-1 clock (minpoll 3 maxpoll 3, the lowest averaged jitter was round 1.7 milliseconds (and even with user-mode PPS it only dropped to 1.55 milliseconds). Adding the kernel-mode driver along reduced the jitter to just under 1 millisecond, about the best which could be expected just using the ~1KHz clock which Windows- provides. However, forcing NTPD to use the interpolation - normally disabled in Vista and Windows-7 - produces an even more dramatic improvement, with the averages jitter dropping to less than 40 microseconds - this is over 40 times better than the jitter using the LAN alone, and 25 times better than the kernel-mode driver alone.
NTP on Windows-7 final - build 7600August 2009 - LAN-synced systemWith the RTM (release to manufacture) version of Windows-7, the performance on the LAN-synced system was much as I reported below with the Release Candidate 1 version. I need to run ntpd 4.2.4p6 to get acceptable performance, as I do on a LAN-synced Windows Vista SP2 system. I did try one small test to improve the performance by reducing the LAN polling interval from 64s to 16s. On my first try at this, NTP 4.2.4 rejected the LAN servers as "minpoll was greater than maxpoll". Dave Hart suggested defining both poll settings in the ntp.conf, so I ended up with a file like: server 192.168.0.2 minpoll 4 maxpoll 4 prefer iburst server 192.168.0.7 minpoll 4 maxpoll 4 server 0.uk.pool.ntp.org minpoll 10 server 1.uk.pool.ntp.org minpoll 10 server 0.pool.ntp.org minpoll 10 server 1.pool.ntp.org minpoll 10 This resulted in the jitter being reduced (64s poll) from an average of around 1.5ms with a range from 1.0 - 5.0ms, to an average value (16s poll) of just under 1ms with a much reduced variation from 1.0 to perhaps 1.2ms. Offset was visibly more tightly controlled, with most offsets being in the range +/-0.5ms, with excursions to +/-1.3ms. With the previous 64s poll the offsets had been typically within +/-1ms, with excursions to about +/-3ms. In the graphs below, the period of 16s polling is from about 08:30 to 15:00, in the centre-left portion of the graphs. I don't have strictly comparable figures for Windows XP working, as during April there may have been more temperature variation. However, the data I do have suggests an offset variation of up to +/-1.7ms, but with a much smoother variation, and a jitter trending towards an averaged value of 40µs, with peaks up to 100-150µs. Windows-7 RTM - August 2009
Windows XP - April 2009
August 2009 - stratum-1 serial GPS systemImmediately after a fresh install of Windows-7 (RTM) on PC Stamsund - a PC running a serial GPS reference clock - I noticed that the performance was actually much better than I had seen with Windows XP. At least, it was until I installed a new network card (at about the middle of the second graph below, around 11:00 UTC).
Ah, you say, poor drivers or something faulty with the new network card. Possible, but not so in this case. Look carefully, and you will see that the 11:00 reboot didn't cause the visible jitter to increase, bit only a subsequent restart of NTP at around 13:30 UTC. As you can imagine, installing the network card required powering the PC down and rebooting. Of course there were then some minor software changes to be made which didn't require reboots, but did require a restart of NTP. As it happened, the beta version of NTPD I was using [ntpd 4.2.5p181-o Jun 06 15:21:08.65 (UTC-00:00) 2009 (1)] happens to have a "defect" whereby the 1KHz clock which may be used by Windows Vista and XP is not detected correctly on a reboot, so the normal interpolation code was used. On the restart of NTP, the faster clock was detected, and the interpolation code disabled. So for Windows-7 do we need a version of NTP which uses the interpolation code even though the 1KHz clock is in use? Here are some event log entries: Warm restart of NTP with the high jitter:Information,22/08/2009 14:28:37,NTP,3,None,Using user-mode PPS timestamp for GPS_NMEA(1) Information,22/08/2009 14:28:36,NTP,3,None,set_peerdstadr(129.215.160.240): change interface from <null> to 192.168.0.7 Information,22/08/2009 14:28:36,NTP,3,None,set_peerdstadr(130.88.200.6): change interface from <null> to 192.168.0.7 Information,22/08/2009 14:28:36,NTP,3,None,set_peerdstadr(87.194.211.97): change interface from <null> to 192.168.0.7 Information,22/08/2009 14:28:36,NTP,3,None,set_peerdstadr(85.234.138.105): change interface from <null> to 192.168.0.7 Information,22/08/2009 14:28:36,NTP,3,None,set_peerdstadr(192.168.0.2): change interface from <null> to 192.168.0.7 Information,22/08/2009 14:28:36,NTP,3,None,refclock_nmea: serial /dev/gps1 open at 4800 bps Information,22/08/2009 14:28:36,NTP,3,None,set_peerdstadr(127.127.20.1): change interface from <null> to 127.0.0.1 Information,22/08/2009 14:28:36,NTP,3,None,set_peerdstadr(127.127.22.1): change interface from <null> to 127.0.0.1 Information,22/08/2009 14:28:36,NTP,3,None,"Listening on interface #5 TCP/IPv6 Interface 1, fe80::5dbb:3fda:3db5:b6be#123 Enabled " Information,22/08/2009 14:28:36,NTP,3,None,"Listening on interface #4 TCP/IP Interface 3, 192.168.238.238#123 Enabled " Information,22/08/2009 14:28:36,NTP,3,None,"Listening on interface #3 TCP/IP Interface 2, 192.168.0.7#123 Enabled " Information,22/08/2009 14:28:36,NTP,3,None,"Listening on interface #2 Loopback Interface 1, 127.0.0.1#123 Enabled " Information,22/08/2009 14:28:36,NTP,3,None,"Listening on interface #1 wildcard, ::#123 Disabled " Information,22/08/2009 14:28:36,NTP,3,None,"Listening on interface #0 wildcard, 0.0.0.0#123 Disabled " Information,22/08/2009 14:28:36,NTP,3,None,proto: precision = 976.500 usec Information,22/08/2009 14:28:36,NTP,3,None,using Windows clock directly Information,22/08/2009 14:28:36,NTP,3,None,"Windows clock precision 0.977 msec, min. slew 6.400 ppm/s " Information,22/08/2009 14:28:36,NTP,3,None,Clock interrupt period 15.625 msec Information,22/08/2009 14:28:36,NTP,3,None,Performance counter frequency 3.580 MHz Information,22/08/2009 14:28:36,NTP,3,None,"MM timer resolution: 1..1000000 msec, set to 1 msec " Information,22/08/2009 14:28:36,NTP,3,None,Raised to realtime priority class Information,22/08/2009 14:28:36,NTP,3,None,ntpd 4.2.5p181-o Jun 06 15:21:08.65 (UTC-00:00) 2009 (1) Cold restart of NTP with the low jitter:Information,22/08/2009 12:08:52,NTP,3,None,HZ 64.000 using 43 msec timer 23.256 Hz 64 deep Information,22/08/2009 12:08:51,NTP,3,None,Using user-mode PPS timestamp for GPS_NMEA(1) Information,22/08/2009 12:08:49,NTP,3,None,set_peerdstadr(192.168.0.2): change interface from <null> to 192.168.0.7 Information,22/08/2009 12:08:49,NTP,3,None,refclock_nmea: serial /dev/gps1 open at 4800 bps Information,22/08/2009 12:08:49,NTP,3,None,set_peerdstadr(127.127.20.1): change interface from <null> to 127.0.0.1 Information,22/08/2009 12:08:49,NTP,3,None,set_peerdstadr(127.127.22.1): change interface from <null> to 127.0.0.1 Information,22/08/2009 12:08:49,NTP,3,None,"Listening on interface #5 TCP/IPv6 Interface 1, fe80::5dbb:3fda:3db5:b6be#123 Enabled " Information,22/08/2009 12:08:49,NTP,3,None,"Listening on interface #4 TCP/IP Interface 3, 192.168.238.238#123 Enabled " Information,22/08/2009 12:08:49,NTP,3,None,"Listening on interface #3 TCP/IP Interface 2, 192.168.0.7#123 Enabled " Information,22/08/2009 12:08:49,NTP,3,None,"Listening on interface #2 Loopback Interface 1, 127.0.0.1#123 Enabled " Information,22/08/2009 12:08:49,NTP,3,None,"Listening on interface #1 wildcard, ::#123 Disabled " Information,22/08/2009 12:08:49,NTP,3,None,"Listening on interface #0 wildcard, 0.0.0.0#123 Disabled " Information,22/08/2009 12:08:49,NTP,3,None,proto: precision = 1.600 usec Information,22/08/2009 12:08:47,NTP,3,None,HZ 64.000 using 43 msec timer 23.256 Hz 64 deep Information,22/08/2009 12:08:47,NTP,3,None,"Windows clock precision 15.625 msec, min. slew 6.400 ppm/s " Information,22/08/2009 12:08:47,NTP,3,None,Clock interrupt period 15.625 msec Information,22/08/2009 12:08:47,NTP,3,None,Performance counter frequency 3.580 MHz Information,22/08/2009 12:08:47,NTP,3,None,"MM timer resolution: 1..1000000 msec, set to 1 msec " Error,22/08/2009 12:08:47,NTP,1,None,"Raised to high priority class, realtime requires Increase Scheduling Priority privilege (enabled with secpol.msc)." Information,22/08/2009 12:08:47,NTP,3,None,ntpd 4.2.5p181-o Jun 06 15:21:08.65 (UTC-00:00) 2009 (1) Using NTPD_USE_INTERP_DANGEROUSFollowing e-mail exchanges with Dave Hart, I tried setting the system environment variable: NTPD_USE_INTERP_DANGEROUS=1 and restarted NTPD (Sun Aug 23 at 17:40 UTC). This produced: Information,23/08/2009 18:39:59,NTP,3,None,Using user-mode PPS timestamp for GPS_NMEA(1) Information,23/08/2009 18:39:58,NTP,3,None,set_peerdstadr(129.215.160.240): change interface from <null> to 192.168.0.7 Information,23/08/2009 18:39:58,NTP,3,None,set_peerdstadr(130.88.200.6): change interface from <null> to 192.168.0.7 Information,23/08/2009 18:39:58,NTP,3,None,set_peerdstadr(62.84.188.34): change interface from <null> to 192.168.0.7 Information,23/08/2009 18:39:58,NTP,3,None,set_peerdstadr(82.219.4.31): change interface from <null> to 192.168.0.7 Information,23/08/2009 18:39:58,NTP,3,None,set_peerdstadr(192.168.0.2): change interface from <null> to 192.168.0.7 Information,23/08/2009 18:39:58,NTP,3,None,refclock_nmea: serial /dev/gps1 open at 4800 bps Information,23/08/2009 18:39:58,NTP,3,None,set_peerdstadr(127.127.20.1): change interface from <null> to 127.0.0.1 Information,23/08/2009 18:39:58,NTP,3,None,set_peerdstadr(127.127.22.1): change interface from <null> to 127.0.0.1 Information,23/08/2009 18:39:58,NTP,3,None,"Listening on interface #5 TCP/IPv6 Interface 1, fe80::5dbb:3fda:3db5:b6be#123 Enabled " Information,23/08/2009 18:39:58,NTP,3,None,"Listening on interface #4 TCP/IP Interface 3, 192.168.238.238#123 Enabled " Information,23/08/2009 18:39:58,NTP,3,None,"Listening on interface #3 TCP/IP Interface 2, 192.168.0.7#123 Enabled " Information,23/08/2009 18:39:58,NTP,3,None,"Listening on interface #2 Loopback Interface 1, 127.0.0.1#123 Enabled " Information,23/08/2009 18:39:58,NTP,3,None,"Listening on interface #1 wildcard, ::#123 Disabled " Information,23/08/2009 18:39:58,NTP,3,None,"Listening on interface #0 wildcard, 0.0.0.0#123 Disabled " Information,23/08/2009 18:39:58,NTP,3,None,proto: precision = 1.400 usec Information,23/08/2009 18:39:55,NTP,3,None,HZ 64.000 using 43 msec timer 23.256 Hz 64 deep Information,23/08/2009 18:39:55,NTP,3,None,"Windows clock precision 0.977 msec, min. slew 6.400 ppm/s " Information,23/08/2009 18:39:55,NTP,3,None,Clock interrupt period 15.625 msec Information,23/08/2009 18:39:55,NTP,3,None,Performance counter frequency 3.580 MHz Information,23/08/2009 18:39:55,NTP,3,None,"MM timer resolution: 1..1000000 msec, set to 1 msec " Information,23/08/2009 18:39:55,NTP,3,None,Raised to realtime priority class Information,23/08/2009 18:39:55,NTP,3,None,ntpd 4.2.5p181-o Jun 06 15:21:08.65 (UTC-00:00) 2009 (1) Using these settings, I am now seeing a better offset performance, but a poorer jitter performance, from this PC under Windows-7 than I did with Windows XP SP3. The high offsets and low jitter of the Windows XP system have been replaced with low offsets at the expense of higher jitter.
Performance with Windows-7 RTM
Performance under Windows XP SP3
NTP on Windows-7 RC - build 7100June 2009On 2009 June 7 Dave Hart announced a new version of NTP, near to a release candidate. However, it was version 4.2.5 which I have seen does not behave very well with Windows Vista or Windows-7 RC 1. For interest, I changed from "ntpd 4.2.4p6@DLH-QPC-o Mar 15 21:30:20.47 (UTC) 2009 (239)" to "ntpd 4.2.5p181-o Jun 06 15:21:08.65 (UTC-00:00) 2009 (1)" however, as before, this version was much worse, as can be seen from the Offset, relative frequency, and jitter graphs below. I don't know whether it might be a clue, but the frequency error estimate seems to have gone from a relatively stable value (within about 0.1ppm) with the (239) software to a value varying by about 2.5ppm (over twenty times less stable), and the jitter has increased from about 1.4ms (average) to something in the order of 10ms. This needs to be addressed, as version (239) shows that this system is capable of much better performance than what is being proposed as the new release.
May 2009On Sunday, 2009 May 03, I installed the release candidate 1 of Windows 7 on a test PC, Hydra. This only has an AMD 3200+, so it's not dual-core and quite low powered, but it does have 2GB of memory. In the past, it has been a good timekeeper when running Windows XP SP3, but as with my other Vista PCs, timekeeping under Windows-7 proved to be rather a disappointment. You can see the effect quite well on the 30-minute average graph below, where the right-hand seven days is with Windows-7.
The configuration for this was two LAN-based stratum-1 clocks with a maxpoll of 64s, and some Internet servers with a minpoll of 1024s. The version of NTP was: ntpd 4.2.4p6@DLH-QPC-o Mar 10 15:23:14.36 (UTC) 2009 (230) As part of the tests on PC Hydra, I wanted to check the SkyStar DVB PCI card which had been used in that PC before. In my early Windows-7 tests the software for this card failed to install, but I discovered on May 10 the correct sequence of installation (which required the drivers to be installed first using the Device Manager and then the application software, as opposed to the usual click-and-install under previous Windows). As reboots were involved, I also took the opportunity to install some Windows-7 updates, and also to test my favourite defragmenting software - mst Defrag. No changes were made to NTP, but there was a very considerable difference in the timekeeping after the change.
I left the weekly graph because although it's similar to the one above, it shows the three regimes quite clearly - XP from Friday to early Sunday on the left, Windows-7 with the USB/DVB box for the majority of the plot, and the Windows-7 PCI/DVB configuration on the right-hand side from late Sunday and Monday. Was this change due to a Windows-7 update, due to adding the defragmenter (sounds unlikely!), or due to changing from the USB satellite data source and DVBWorld software to the SkyStar PCI card and TechniSat Software? The tests continue, and suggestions are welcome! One measurement which we can make is the DPC Latency, with a free test program.
NTP on Windows VistaMarch 2009Some further casual tests on the effect of maxpoll on jitter were carried out during March 2009. They showed that with a large maxpoll, and hence a longer time between corrections, the observed variation in offset was greater.
In the graph above, the PC started off with maxpoll=6, so that NTP would make its calculations and corrections every 64 seconds. Despite their being mostly a flat line, there are still some excursions of up to 60ms, although these are often short-lived. At time A, the maxpoll was reset to 10, typical of using the PC with just Internet servers. At time B the maxpoll was experimentally set to just 4 (16 seconds), and the minpoll also had to be set to 4 to override its normal minimum value of 6 (64s). Because of the load this would create, just one local PC was selected as a server. Although the jitter is much reduced, there are still some transients visible. You can download a Zip file with all the loopstats for PC Gemini on request, and there is a program to display them here. On March 10 and 11, I noticed that there was a glitch in timekeeping at about 0200 on both days. This seems to coincide with an automated system restore, download of Windows Defender definitions, and a run of Windows Defender. That whole sequence seems to start two minutes early - at 0158. Whilst I haven't been aware of this before, I would like to know which of those three elements may be the cause of the problem, so I shifted Windows Defender to do the same operation at 0400 instead of 0200 and we'll see if the glitch shifts. This was with Gemini syncing to one stratum 1 and two stratum 2 servers just on my LAN, with a maxpoll of 6 (64 seconds). C:\>ntpq -p gemini remote refid st t when poll reach delay offset jitter ============================================================================== *feenix .GPS. 1 u 51 64 377 0.977 0.919 2.726 stamsund 192.168.0.2 2 u 57 64 377 2.709 -1.341 3.103 narvik 192.168.0.2 2 u 28 64 377 0.977 6.590 8.489 Windows DefenderI happened to notice that there were regular timekeeping steps at 0200 every morning, when Pixie was running with maxpoll=6 using just LAN servers. Looking at the Application and System event logs suggested that Windows Defender was being run at that time, following a definitions download. As that PC isn't used a lot for interactive use, I decided to change the daily schedule for the program to being just Wednesdays. Not that I have anything against Wednesdays, of course! I hadn't seen this behaviour before, though. This page says more about the program. ThanksWith the new version of the Windows NTP port by Dave Hart, we have come much closer to Vista offering an acceptable performance for NTP, and with his suggestions and expertise we have been able to achieve some very good results. My thanks to Dave for his time and ideas.
February 2009In late January 2009 I received an interesting e-mail from Dave Hart, offering an improved NTP for Vista. We worked together testing the changes which Dave had made, and the result as of mid-February 2009 was as shown below.
The amplitude of the oscillations has been reduced, and the peaks seem smoother and more rounded to me. Quite why the oscillations still exist is a mystery to be, as are two other effects seen on Vista - the ability to run for a period with no oscillations (such as in the Puffin graph below), and the apparent ability for a system to be more stable after restarting NTP. Yes, I did check that the drift file exists, has a reasonable value, and is being updated. We have continued to experiment with this, and by using /just/ the local stratum 1 GPS/PPS server, and with a reduced, non-standard poll interval of 64s (maxpoll 6), the jitter could be brought down to a very low value, with a typical offset of -0.6ms. With maxpoll 8, the typical offset was -7.5ms with transient offset peaks up to +0..+2.5ms with a couple up to +17..18ms (i.e. an excursion of 7.5..10ms and 24.5..25.5ms). With maxpoll=9, the jitter shows peaks up to 20-30ms, many of which are positive. As of March 06, I know that Dave Hart is still playing with some algorithm tweaks, but I am uncertain whether these will affect the Vista performance shown above, of whether they are just for use with a local serial-input reference clock. Clarification from Dave Hart: The vista interpolation disabling has hardly blinked since I first
wrote it. Operationally, there hasn't been a difference with any of my released versions' Vista-specific code.
However, there was a period of as much as a week (I forget exactly) where my binaries
failed to try to raise the priority unless -N was given on the command line, and that (running at normal instead of high or
real-time) definitely dragged down performance on Vista as well as other Windows releases. 6 January 2009I tried an experiment with Cecilia's new PC, adding NTP to what is a fairly empty Windows Vista Home Premium SP1 system. I wanted to see whether the poor performance seen in September 2008 was typical of Vista, or just typical of the system I was then using. Initially, the results were promising, as, after the initial transient (as NTP had never been run on that PC before, times B to C on the graphs below), the offset seemed to be just a noisier-than-expected straight line. See the PC Puffin on the graph below. However, after about 17 hours, time D, there was a negative spike in the offset, followed by a period of greater instability of around 50ms peak-to-peak. I therefore tried the main Vista system with none of the applications I normally run started up (Dexatek DVB RX, TelliCast, MSG Data Manager, AVHRR Manager, Metop Manager, SBS-1 BaseStation, GAS populate, Plane Plotter and Flight Display). I rebooted at about 07:00 - time A on the graphs below. However, the oscillations started after about one hour, so I restarted all the normal apps at 08:48. The resulting instability on the PC Gemini is perhaps greater than on PC Puffin, being over 100ms peak to peak.
Questions which remain:
For interest, I tried logging the user out of PC Puffin at 14:27, to see if that makes any difference or not. Unfortunately, with the particular wireless network USB stick I have for that PC, logging out stops the network connection, so I now have an hour of zero results! The network was reconnected at about 15:30, and instability similar to the other Vista PC continued.
December 2008 - a small discovery about VistaThis link http://17slon.com/blogs/gabr/2007_11_01_archive.html
mentions that the timing resolution on Vista is improved to 1 millisecond, and
there is a link to a note from Microsoft (http://support.microsoft.com/kb/274323)
which mentions that the "Performance counter value may unexpectedly leap
forward" with certain chipsets. I don't know whether either of these
would affect NTP. September 2008Following a suggestion from Mike Hughes, I tried setting CPU affinity for the NTPD process on the Vista PC, Gemini, to just a single CPU. I happened to choose CPU 1. It seems to have helped Mike get better timekeeping. Mike may force CPU on the ntpd.exe with the ImgeCfg.exe program, if the improvement continues. However, it didn't seem to help me a lot, so I tried stopping ntp service, marking the image uni-processor only, and CPU-affinity 0x1 (i.e. CPU 0), and restarted. See: windowsitpro.com article and and brinkster.com article about using imagecfg.exe. On looking back, it may have helped reduce the noise as seen on the 30-minute average graph, looking at the data from mid-Thursday onwards it perhaps has less variation than that from before. However, looking at the monthly 2-hour average graph, the change is less visible, so it may be a random effect after all. The gross variations seen on a 5-minute average continue, however.
June 2008Well, 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 nodes. 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 2007I 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 no longer available. 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 a local GPS NTP source which is good to within 20 microseconds.
NTP Events loggedTo 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 observedThere 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 ticksI 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"
| |||||||||||||||||||||||||||||||||||
|
|
