Daily Timekeeping Accuracy (or otherwise...)

	PC Pixie 133MHz Pentium, 48MB FreeBSD 5.4 Server NTP 4.2.0-a (May 08 2005) GPS18LVC & PPS reference
	PC Bacchus Intel PIII 550MHz, 512MB Windows 2000 Server APT RX NTP 4.2.4 (1502) Synched from PC Pixie
	PC Gemini AMD-64 X2 4400, 3GB Windows Vista Ultimate Test-bed NTP 4.2.4 (1502) Synched from PC Pixie
	PC Hermes 1GHz Pentium III, 512MB Windows 2000 Pro SP4 EUMETCast - main Server NTP 4.2.4 (1502) Synched from PC Pixie
	PC Hydra AMD 64 3200+, 2GB Windows XP home EUMETCast - test Server NTP 4.2.4 (1502) Synched from PC Pixie
	PC Narvik Intel E6600, 3GB Windows XP Pro Interactive NTP 4.2.4 (1502) Synched from PC Pixie
Click on a graph for weekly, monthly and yearly data	PC Stamsund 2.8GHz Pentium 4 HT, 3GB Windows XP Pro EUMETCast backup Interactive NTP 4.2.4 (1502) Synched from PC Pixie

Please note, because I happen to use MRTG to gather and plot this data, and negative values aren't allowed, I needed to add a 100ms bias to the actual offset to derive the graphs above (20盜 for the much more accurate PC Pixie). An ideal timekeeper would therefore display a straight line at the 100ms level. The value plotted is the offset from the server clock that the NTP servers on each of the PCs reports when interrogated, every five minutes. There appears to be an oddity with MRTG in that is looses small figures in the year data, so the gradual drift upwards of Pixie since it started is probably just a recording artefact.
How I obtain this data.

Configuration changes and other events

Please note that some transients are caused by system reboots, e.g. after a security update, and these events are not usually individually recorded.

0545 UTC, Thursday, 2008 Jun 19, week 25. The Vista system downloaded service pack 1 yesterday, and invited me to install it this morning. So far, NTP seems as good now on Vista as it was on XP, but that's only a three hour spell.
0756 UTC, Wednesday, 2008 Jun 18, week 25. On Vista, set system environment variable RANDFILE=C:\Tools\NTP\etc\.rnd, so that NTP might be able to access the file. Used this directory as it already exists on my system, and it's where I write the NTP statistics. This is in the hope that NTP time keeping on Vista might improve, but I am not optimistic about this! No significant change noted.
0530 UTC, Tuesday, 2008 May 27, week 22. Discovered that the W32Time service was still running on Gemini, despite me asking the Meinberg installer to disable it. Probably needed more privilege. Disabled manually, and lets see how it goes.....
1330 UTC, Thursday, 2008 Apr 03, week 14. Changed the LED in the Pixie GPS interface, and it will take a little more current (around 2mA), but be a lot brighter. Seems to have caused some oscillation in the timekeeping, but settled down OK after a few hours.
1730 UTC, Tuesday, 2008 Feb 26, week 9. EUMETCast signal loss and NTP restarts will cause transients on PCs Hermes, Hydra and Stamsund.
Thursday, 2007 Dec 20, week 51. Only discovered on Sunday Dec 23 that the PSU fan on Bacchus had stopped, so PC replaced with a spare one on Monday, Dec 24.
2200 UTC, Tuesday, 2007 Nov 13, week 46. Restart Gemini with Windows Vista. Some issues with Vista, currently under investigation.
1725-1737 and 2012-2034 UTC, Tuesday, 2007 Nov 13, week 46. power outage.
2345 UTC, Monday, 2007 Oct 22, week 43. Break in EUMETCast from 2345-2359, and 0029-0042 (Tuesday 23). On Hermes and Hydra, the timekeeping suffered a glitch. Stamsund OK.
0020 UTC, Monday, 2007 Oct 01, week 40. Seems to have been some sort of transient causing Bacchus to go wild, leaving a large positive value (494.739) in the drift file. Restarted NTP OK at 0525 with a drift value which was approximately correct (-72.717). Gemini and Hermes also showed a small glitch around that time, and Hydra nearer 0100. Unsure what this was. Spurious leap-second flag on Bacchus? Yes, it inserted a leap-second at 0100 clock. None of the currently selected servers show a +1 second offset.
0520 UTC, Tuesday, 2007 Aug 21, week 34. Rebooted Bacchus, which seemed to cause quite a transient!
1845 UTC, Sunday, 2007 Aug 19, week 33. EUMETCast drop-out triggered NTP transients on Hermes and Hydra. PC Stamsund, with its older V2.3 card, had a TelliCast restart and therefore an NTP restart.
0600 UTC, Sunday, 2007 Aug 12, week 32. Discovered that NTP had fallen over on Bacchus with an access violation. Message logged at 02:37 on Aug 09 "no servers reachable". Restarted OK but with a visible transient.
1510 UTC, Tuesday Jul 31, week 31. Updated NTP on the Windows 2000 system to "ntpd 4.2.4p3@1.1502-foehr-o". A new installer has resolved the LIBEAY32.dll error, and there were other problems due to having an earlier installation living in the \WinNT\ directory. Resolved by not doing a files-only upgrade, and editing the ntp.conf appropriately.
0820 UTC, Friday Jul 27, week 30. Updated NTP on the XP machines to "ntpd 4.2.4p3@1.1502-foehr-o". The Windows 2000 system failed with "The ordinal 3837 could not be located in the dynamic link library LIBEAY32.dll". No upgrade attempted on the one Windows NT4 system.
1146-1149 UTC, Friday, Jul 20, week 29, EUMETCast drop-out triggered NTP transients on Hermes and Hydra.
0400 - 0430 UTC, Friday Jun 29, week 26. Upgraded PCs Hydra, Narvik & Stamsund to Meinberg NTP V1.1499 (V4.2.4p3-RC1). This does not appear to work correctly on PC Bacchus which runs Windows NT4 SP6, and hence the glitch while reverting to the older Terje Matheson version.
0546 UTC, Thursday Jun 28, week 26. Upgraded PC Gemini to Meinberg NTP V1.1499 (V4.2.4p3-RC1) as a test. Seems to be OK.
0317-0325 UTC and 1141 - 1146 UTC, Thursday, Jun 21, week 25. EUMETCast outages caused timekeeping glitches on Hermes and Hydra.
1700-1730 UTC, Sunday Jun 10, week 23, EUMETCast outages caused timekeeping glitches on Hermes and Hydra.
1330 UTC, Saturday Jun 09, week 23, EUMETCast outage caused timekeeping glitches on Hermes and Hydra.
2100 UTC, Friday Jun 01, week 22. Experiments on Gemini setting the time zone between UTC (Casablanca) and GMT/BST (Edinburgh) seem to have upset NTP, so restarted it from scratch at about 06:10UTC on Saturday, June 02. Still not settled by 07:00 UTC, and the drift value showed 481, so created a small reset file to stop, set the correct drift value, and restart NTP. Ran at 07:03 UTC.
0015 and 1926 UTC, Saturday May 26, week 21. EUMETCast drop-out triggered auto-restart and hence timekeeping glitches.
2145 UTC, Monday, 2007 May 07, week 19. EUMETCast drop-out triggered auto-restart and hence a timekeeping glitch on Hermes, Hydra but not Stamsund.
0530 UTC, Saturday, 2007 Mar 31, week 13. Discovered that NTP had fallen over on Bacchus with an access violation. Restarted OK but caused a transient lasting to ??.
1930 UTC, Sunday, 2007 Mar 18, week 11. Discovered that NTP had fallen over on Bacchus with an access violation. Restarted OK but caused a transient lasting to 0300 Monday.
0807 UTC, Monday, 2007 Mar 05, week 10. Discovered that NTP had fallen over on Bacchus with an access violation. Only logged event was Mar 02 at 1825 "no servers reachable". Restarted OK but caused a transient. Seems same as Jan 05 event?
0820 UTC, Thursday, 2007 Feb 01, week 5. There was another glitch which caused a timekeeping step on the Test PC, and required an NTP restart on the main PC.
07:50 UTC, Thursday, 2007 Feb 01, week 5. Test PC (Hydra) lost EUMETCast connection for more than 90 seconds, the automatic restart causing a slight glitch.
0424 UTC, Friday, 2007 Jan 19, week 3. EUMETCast drop-out triggered restart event on Hermes. Hydra timekeeping affected.
1750 - 1820 UTC, Thursday, 2007 Jan 18, week 3. EUMETCast drop-out on all three PCs affected timekeeping.
0945 UTC, Thursday, 2007 Jan 11, week 2. Rebooted Bacchus after monitor change caused the system to hang (may have disturbed mouse connection at the same time). Bacchus seems to have ignored the ntp.drift file, or somehow entered a wrong value (-20) there. Reset to near-correct value of -72 and restarted at 1415 UTC.
0923 UTC, Friday, 2007 Jan 05, week 1. Discovered that NTP had fallen over on Bacchus with an access violation. Only logged event was Jan 02 at 1733 "no servers reachable". Restarted OK but caused a transient.
~2200 UTC, Friday, 2006 Dec 22, week 51. Added PC Narvik as replacement for Gemini.
0700 UTC, Sunday, 2006 Dec 17, week 50. PC Gemini rebooted after monthly security update and Zone Alarm update.
0200 UTC, Friday, 2006 Dec 15, week 50. EUMETCast seemed to drop out on Hermes and Hydra, but OK on Stamsund (older V2.3 card). NTP consequently affected. Two more drops at 2047 and 2153, handled by automatic restart on Hydra.
0200 UTC, Wednesday, 2006 Dec 13, week 50. EUMETCast seemed to drop out on Hermes and Hydra, but OK on Stamsund (older V2.3 card). Hydra also showed a drop from 1000 to 1100 (from about 9dB to 7.5dB). NTP also affected.
~2230 UTC, 2006 Nov 29, Wednesday, week 48. Glitch on EUMETCast caused PC Hermes and Hydra to stop collecting, so I restarted NTP as a precaution.
0155 UTC,2006 Nov 27, Monday, week 48. Glitch on EUMETCast stopped Hydra and caused timekeeping transient. NTP restarted at 1850.
0130 UTC, 2006 Nov19, Sunday, week 46. Timekeeping glitch on Hydra suggests EUMETCast transient.
1440 UTC, 2006 Nov 17, Friday, week 46. Stamsund rebooted after security updates.
1625 UTC, 2006 Nov 15, Wednesday, week 46. Noted that Bacchus timekeeping had been a straight line so looked rather good. Further checks showed that NTP had crashed with a memory access violation, with "no servers reachable" in the event log at 20:04:55 on Sunday Nov 12. Restarted.
0140 UTC, 2006 Nov 02, Thursday, week 44. Seemed to be a glitch on both Hydra and Hermes, so I suspect a EUMETCast glitch. Another smaller glitch at 0605 UTC.
1500, 2006 Oct 18, Wednesday, week 42. Rebooted Gemini after hardware hang.
1500, 2006 Oct 12, Thursday, week 41. Large tree at the house front cut down, which should have the incidental effect of improving the GPS coverage slightly.
0910, 2006 Oct 10, Tuesday, week 41. Stamsund spontaneously reboot during a period of high network activity, and I took the opportunity to update the Zone Alarm. Hence the glitch.
0843, 2006 Oct 04, Wednesday, week 40. Rebooted Bacchus, because the CMOS clock will likely have been well of when the system restarted, so making the 16-bit sub-system time incorrect..
0500 - 0630, 2006 Oct 04, Wednesday, week 40. Power failure will have upset timekeeping.
1030, 2006 Sep 22, Friday, week 38. Repositioned GPS antenna for Pixie onto the roof. This should give it a good vertical view and remove the 180 degrees restriction due to the house, but may restrict the view near to the horizon.
1140, 2006 Sep 21, Thursday, week 38. Due to building maintenance, temporary loss of EUMETCast signal caused Hermes NTP to go wild. I wonder if the TCP/IP stack is getting overloaded by repeated "where-is-the-signal" activity and delaying NTP requests? Restarted NTP on Hermes around 1200.
0715, 2006 Aug 26, Saturday, week 34. Rebooted Hydra to correct EUMETCast signal strength reporting. 0730 rebooted Stamsund for the same reason (this made no difference).
0900, 2006 Aug 25, Friday, week 34. Loss of EUMETCast signal caused Hermes and Stamsund to loose proper timekeeping (they were increasingly slow while the red satellite icon was displayed), so restarted NTP. Both Hydra and Stamsund were rebooted after security updates were applied. NTP again failed to pick up the UK pool servers on the rebooted PCs, so added one other external stratum 2 server into the configuration.
0245, 2006 Aug 18, Friday, week 33. Loss of EUMETCast signal (or high error rate on the Usingen upload), caused NTP on Hermes and Hydra to go wild. Restarted with a near-correct drift file. Stamsund appears to have survived OK.
1130, 2006 Aug 14, Monday, week 33. Restarted NTP on Hydra to enable statistics collection.
0030 - 0300, 2006 Aug 13, Sunday, week 32. Local power cut, so all PCs restarted manually (except the older Pixie and Bacchus which automatically restarted). Bacchus seems to have -10 instead of -75 for drift, so copied the more correct drift file and restarted NTP.
1600, 2006 Aug 08, Tuesday, week 32. GPS source lost sync altogether and had to be rebooted (switched off and on again). No obvious reason, unless it's too few satellites. Only noticed this at 0820 on Wednesday 9th!
1000 - 1900, 2006 Aug 07, Monday, week 32. PC Stamsund rebuilt wit Windows XP Pro.
1855 - 1940, 2006 Aug 03, Thursday, week 31. PC Gemini froze and had to be manually rebooted.
1456 - 1522, 2006 Aug 03, Thursday, week 31. PC Stamsund was down for maintenance. Memory upgraded from 1 to 3GB, and thoroughly cleaned!
1100, 2006 Aug 03, Thursday, week 31. Discovered that Hydra's NTP had stopped, because Hydra was not connected to the network when booted. Restarted NTP. It would be helpful if NTP attempted to repair connections itself rather than just giving up.
~0900, 2006 July 17, Monday, week 29. Gemini rebooted after a hang, and then security upgrades.
1903, 2006 July 15, Saturday, week 28. Discovered that NTP had stopped on Bacchus, perhaps at 0748 on Friday, with a "No servers reachable" event log message. Restarted, and the initial offset was +74msec.
2000, 2006 July 10, Monday, week 28. GPS source lost sync, and the PPS signal did not re-appear. Power cycled at 0500 Tuesday. What is happening here?
1830, 2006 Jul 08, Saturday, week 27. Pixie seemed to loose sync with its GPS/PPS source. Could have been 2030. Sunday 0710 discovered this. No flashing PPS pulses from the GPS, so powered down GPS and restarted it. PPS pulses OK within less than a minute, and Pixie regained sync.
1640, 2006 Jul 05, Wednesday, week 27. A thunderstorm with lightning (helped by the rain?) may have stopped the GPS 18 LVC working. Power off and on restored operation, although it took a few minutes after power on before the PPS pulses appeared. EUMETCast loss of signal at the same time. This seems to have started as a lack of satellite signals (?) around 1415 UTC, although the EUMETCast outage was between about 1500 and 1530 UTC. Perhaps these events were not related? The EUMETCast outage caused NTP to go wild on Hermes and Hydra, but I detected this (by ear) and manually restarted NTP on those systems.
0715, 2006 Jul 01, Saturday week 26. Timekeeping on both Bacchus and Stamsund had gone wild since about midnight UTC, with incorrect very large drift values (over 400) being recorded in ntp.drift. Both these PCs are 100% reliable. Reset drift file to correct content and restarted ntp. This is just like what happened at the new year, with the leap second. Could it be that some of the Internet servers these PCs were seeing were still sending the leap second flag? See: ntp-events.
1900, 2006 Jun 25, Sunday, week 25. Restarted NTP on Hermes as the DVB reception system restarted (due to satellite signal loss - bad weather over Germany), and the automatic restart caused a transient.
1300, 2006 Jun 18, Sunday, week 24. Restarted NTP on Hermes with -94.557 as the drift value.
~1100, 2006 Jun 17, Saturday, week 23. Transient on Hermes due to signal loss and re-acquisition on DVB system. Although signal was back OK, the NTP software seemed to "go wild".
2006 Jun 11, Sunday, week 23. Some sort of transient or issue on Pixie seemed to stop its precision lock for a period, but it recovered.
1146, 2006 Jun 07, Wednesday, week 23. Checked that the GPS 18 LVC really was in 2D, and it was. No improvement seen, so probably the glitches are not loss of satellites. Ah, well!
0955, 2006 Jun 07, Wednesday, week 23. Reboot Gemini to get network cards back to standard IDs for MRTG.
0810, 2006 Jun 06, Tuesday, week 23. Attempted to set GPS 18 LVC to 2D mode, so that fewer satellites are required to get a time "fix", but I'm not sure if this worked.
0750, 2006 May 31, Wednesday, week 22. Gemini rebooted after a security update.
2006 May 19 - 22, week 20-21. Gemini hang followed by a reboot late Monday 22.
0700, 2006 May 12, Friday, week 19. Stamsund rebooted after security update.
1645, 2006 May 11, Thursday, week 19. Hermes rebooted after update of TelliCast client software.
1530, 2006 May 09, Tuesday, week 19. Found that the ntp.drift file on Gemini contained 9 0x00 bytes, and that ntp.drift.TEMP had the correct value. Could not delete ntp.drift, and the permissions were correct. Stopped NTP, and copied ntp.drift.TEMP to ntp.drift. Restarted NTP OK.
0000 (clock) 2006 May 06, Saturday, week 18. Hermes had about a +80ms time step, and gradually recovered back to zero. No obvious cause. There was a EUMETCast issue at almost exactly the same time - a co-incidence? Had been up for about 80 days 1h 45m, and is still running without a reboot.
1120, 2006 Apr 09, Sunday, week 14. Noted that Gemini USB WiFi hadn't restarted after the reboot, so unplugged and re-plugged the adaptor. This seemed to kill NTP, and it was manually restarted at 1435 when it showed a 30ms offset.
1530, 2006 Apr 05, Wednesday, week 14, took Gemini down for about an hour to add a fan to the hard disk bays. Will be interesting to see any effect or not on the diurnal offset. Disk temperatures about 17蚓 lower.
1600, 2006 Feb 10, Saturday, week 6, removed Odin after 4 years service, it will be replaced by Gemini.
1110, 2006 Feb 01, Wednesday, week 5. Rebooted Pixie following a request for a test.
1400, 2006 Jan 30, Monday, week 5. Made all four PCs sync to Pixie as a preferred server. Slight glitch resulted.
1100, 2006 Jan 30, Monday, week 5. Finally got kernel recompiled on FreeBSD PC (pixie - it took 5 hours!) and enabled the PPS stuff. Will keep an eye on this before changing the other servers.
0730, 2006 Jan 30, Monday, week 5. Some sort of glitch on Hermes seeming to stop DVB reception. DVB restored at 0745, but there was a timekeeping transient just after 0800 with a step of approximately 75ms. Why? There is nothing in the event log.
1700, 2006 Jan 29, Sunday, week 4. Add new FreeBSD system with GPS NMEA - Pixie. Discovered that you need to re-compile the FreeBSD Kernel to enable PPS support, so this is in progress.
1600, 2006 Jan 28, Saturday, week 4. Add GPS NMEA-only reference clock to Odin for testing. Looks like the 4800 baud serial output is about 200msec earlier than the (unused) PPS signal, but this can be fudged. Jitter is bad (up to 10ms), so it will be interesting to see how this shows on the plots. Lots of errors "clock GPS_NMEA(1) event 'clk_fault' (0x03)" so I've abandoned this at 1715.
0800, 2006 Jan 14, Saturday, week 2. Daily drift on Stamsund and Odin is more than I like, so reset the maxpoll to the local servers to 9 (512 seconds).
1100 - 1500, 2006 Jan 13, Friday, week 2. Odin down and rebooted following peculiar hang.
2030, 2006 Jan 11, Wednesday, week 2. Removed all MaxPoll lines from Odin and Stamsund to see how they get on in a "default" configuration. This should make all servers MaxPoll 1024 seconds.
1000, 2006 Jan 11, Wednesday, week 2. Removed the "prefer hermes" line from Odin and Stamsund in case yesterday's events should happen again. At least with Bacchus remaining stable, perhaps these clients would not have behaved as badly.
2100, 2006 Jan 10, Tuesday, week 2. For some reason, Hermes NTP went wild. About 1 hour later, Odin started going wild, and nearly three hours later Stamsund joined the wild bunch! PC Bacchus showed no problems, perhaps showing the Internet connection stayed OK (the traffic looked normal). PCs Odin and Stamsund only showed changes of selected server. At 2119 Hermes changed to server 130.88.200.6 (utserv.mcc.ac.uk) and suffered an immediate time reset of +0.194392s. It continued seeing time resets until 06:43:15 on Jan 11, and seems to have been able to recover without further resets since then. There's nothing in the event log to suggest any other problems around the time when NTP on Hermes went wild, however, at 2105 there was a burst of wind which caused momentary loss of a satellite signal. Perhaps a mains glitch?
1350, 2006 Jan 09, Monday, week 2. Rebooted Hermes after addition of RAMdisk and Windows security updates.
0910, 2006 Jan 06, Friday, week 1. Rebooted Odin after official WMF security update.
1000, 2006 Jan 04, Wednesday, week 1. Rebooted Odin and Stamsund following WMF security patch update.
1500, 2006 Jan 02, Monday, week 1. Decided to replace older NTP software on Hermes and Bacchus by the more leap-second complaint version. Perhaps should have done this before the leap-second rather than after!
0740, 2006 Jan 01, Sunday, week 1. Hermes and Odin had not settled down after the leap second, and the drift files values were very big (over 400), so stopped ntpd on those systems, deleted the drift files, and restarted. Ntpd seems to have some instability judging by the offset graphs. Bacchus (drift -55.3) and Stamsund (drift -11.5) did seem to be sorting themselves out, albeit slowly. See: ntp-events.
2010, 2005 Dec 26, Monday, week 52. Advised that having a large difference between MaxPoll and MinPoll was not a good idea. "You have forced the poll interval and time constant to 64 s. Should that source fail and the host switch to another source with poll interval clamped to 1024 s, the discipline loop is seriously undersampled and could well become unstable.", so reset Odin and Stamsund to MaxPoll=8 as a compromise.
0735, 2005 Dec 24, Saturday, week 51. Updated Odin and Stamsund to have MaxPoll 6 on internal LAN servers and MinPoll 10 for their Internet servers. This provides a fast response while minimising the load on the backup servers.
1530, 2005 Dec 22, Thursday, week 51. Updated Odin and Stamsund Meinberg ntp-4.2.0b@1.1436mbg-xmas version. This accepts the -M parameter to enable the MM timer while ntpd is running, so I could now disable this frig in my own program on Odin. SSL library updated on Odin. [Didn't use the Meinberg installer].
1125, 2005 Dec 20, Tuesday, week 51. Changed Odin and Stamsund from 128s poll to default 1024s poll. Since the steps are gone, there is no need for the shorter poll interval. Noted that Bacchus seems to have rather more drift than Hermes, even though both are nominally synced the same.
0639, 2005 Dec 13, Tuesday, week 50. Restarted NTP on Stamsund to collect loop statistics. Noted that this caused an initial 20ms offset.
1855, 2005 Dec 12, Monday, week 50. Installed experimental NTP version on Stamsund. Version: ntpd 4.2.0b@1.1432-o Dec 12 17:03:03 (UTC+01:00) 2005 (43) from Meinberg. Needed to edit the Image path in the registry to include a "-M" parameter to force the MM timer to 1ms resolution. Having this parameter present caused previous NTP versions to fail. Needed to update the SSL libraries as well.
0910, 2005 Dec 09, Friday, week 49. Tried the same "force MM timer to 1ms" experiment on Stamsund, as a test.
1700, 2005 Dec 07, Wednesday, week 49. Started running QuickTime player permanently on Odin to force the MM timer to run with a 1ms period. Seems to have stopped the violent swings. Looks as if the MM timer was permanently running on Odin until Friday, Dec 05.
1030, 2005 Dec 06, Tuesday, week 49, updated all systems to V4.2.0b from Terje Matheson ("ntpd 4.2.0b@1.1431-o Dec 06 10:23:21 (UTC+01:00) 2005 (1)")
0941, 2005 Dec 05, Monday, week 49, replaced older 2003 V4.2.0 ntpd on Odin by V4.2.0a from Meinberg 1370 download. The jitter still seems high. Version numbers were: old: ntpd 4.2.0 fr Oct 17 8:49:33 2003 (1), new: ntpd 4.2.0a@1.1370-o Apr 12 14:10:45 (UTC+02:00) 2005 (12). Also, at 1310 replaced Stamsund's ntpd.exe with the Meinberg 1370, as a test to see if the extreme swings were any different.
1500, 2005 Dec 02, Friday, week 48, something has upset the otherwise excellent timekeeping on Odin. Tried to get rid of this on Saturday by reboots at 1100, 1800 and 2100. Can't discover what the problem is. See: ntp-events.
1830, 2005 Oct 27, Thursday, week 43, reverted to maxpoll 10 on Bacchus as no permanent change noted.
0800, 2005 Oct 04, Tuesday, week 40, changed maxpoll interval on Bacchus from 10 down to 9 to reduce diurnal variation.
0820, 2005 Sep 09, Friday, week 36, found that local ISP head-end was no longer offering NTP services so switched to a different external server.
2230, 2005 Sep 06, Tuesday, week 36, power glitch takes down systems from about 1600 to 2230
0830, 2005 Aug 16, Tuesday, week 33, was moved by ISP onto a different upstream connection to the cable modem service. Watch and see if there is any improvement. Yes (two days later), it's much better. Thanks for an understanding ISP!
1510, 2005 Aug 11, Thursday, week 32, noted more noise over the last couple of weeks or so, so added another two NTP pool servers to Hermes as a test.
1510, 2005 May 28. Saturday, week 21, remove NPL servers from Bacchus - too noisy because too many servers?
1830, 2005 May 27, Friday, week 21, remove NPL servers from Hermes - too noisy?
2205, 2005 May 25, Wednesday, week 21, added NPL servers to Hermes & Bacchus.
0000, 2005 Mar 25, Friday, week 12, Blueyonder network maintenance causes glitch.
0930, 2005 Feb 04, Friday, week 05, moved Bacchus and Hermes onto NTP Pool Internet servers.
2230, 2005 Feb 03, Thursday, week 05, a Blueyonder network problem in Scotland causes another glitch.
1200, 2005 Jan24, Monday, week 04, reboot of Odin following internal problem.
2300, 2005 Jan 15, Saturday week 02, a Blueyonder network problem in Scotland causes another glitch.
1900, 2005 Jan 03, Tuesday week 1, some sort of disruption of level 3 links at Blueyonder cause transient glitch in timekeeping.
1945, 2004 Nov 16, Tuesday week 46, add 'prefer' option to Hermes entry in Odin & Stamsund's configuration
1200, 2004 Nov 16, Tuesday week 46, major configuration change, Bacchus & Hermes sync to the Internet, Odin and Stamsund sync to Bacchus and Hermes. This change because Hermes is really an always-on and lightly loaded server.
0930, 2004 Nov 10, Wednesday week 45, made Stamsund not have Tinker Step 0.050 to see if the extreme swings were handled any better. Not sure what is causing the swings.
2004 Nov 06, Saturday week 44, multiple reboots of Stamsund to update DVB card drivers
2004 Nov 05, Friday week 44, multiple reboots of Hermes to update DVB card drivers
1830, 2004 Sep 27, Sun week 39, power glitch required reboots of all PCs
2004 Sep 15, Wed week 37, lost Internet connection for 4.5 hours
1400, 2004 Mar 08, Mon week 9, tested one PC as an Internet server. As the bandwidth throttling appears not to work, it eats all the upstream bandwidth and therefore clobbers timekeeping.
0800, 2004 Mar 05, noted that on Odin & Hermes there were some 10ms steps, and that the Internet servers were 1024s maxpoll (10). Altered the configuration to make them maxpoll 7 and restarted.
2030, 2004 Mar 04, increased maxpoll to 7 (from 6) on Odin & Hermes. Hermes & Odin not seeing the external servers, although they had 6 hours and 42? hours ago!
1200, 2004 Feb 26, changed external server, rebooted Odin & Stamsund. Hermes & Stamsund not seeing the external server. Why not?
1705, 2004 Feb 24, removed Stamsund as peer for Hermes and Odin. Hermes still not seeing the external server.
0037, 2004 Feb 21, Sat, changed the external network server. Hermes still not seeing the external server, Odin got a 30ms step during service restart sequence.
1638, 2004 Feb 14, Sat, as an experiment, added one more external network server to Hermes, Odin and Stamsund. Note that Hermes is in the state of not talking to external servers.
1230, 2004 Feb 03, Tue, a power cut at 1150 resulted in all PCs being rebooted at 1235.
1145, 2003 Dec 05, Fri, a reboot of Odin again gave a large step and slow recovery cf. mid-November.
1205, 2003 Nov 18, Tue, added tinker step 0.050 to try and avoid these large steps on reboot (Hermes, Odin, Stamsund).
0915, 2003 Nov 16, Sun, Bacchus performance not so good, nor the rest of the network, so reverted to no "prefer".
1740, 2003 Nov 15, Sat, gave Bacchus a "prefer" server as it was clock-hopping.
1415, 2003 Nov 09, Sun, restored Hermes/Odin/Stamsund peering, in view of the number of reboots that Hermes is requiring.
1900, 2003 Nov 08, Sat, replaced Hermes with a different PC (actually old Wotan).
1000, 2003 Nov 07, Fri, Hermes rebooted at 1000, DVB card added to Stamsund.
2003 Nov 04, for operational reasons, Hermes required a number of reboots, and seems to have lost accurate drift information.....
1745, 2003 Nov 01, Sat, noticed that Stamsund is noisy (doing large panoramas!), so remove it from peering with Hermes and Odin.
1000, 2003 Oct 31, Fri, added one more server to Bacchus.
2115, 2003 Oct 30, Thu, noticed that Bacchus was more noisy, so tried a "burst" option on one server.
1834, 2003 Oct 28, Tue, PC Wotan replaced by PC Stamsund.
0815, 2003 Oct 26, Sun, reset Bacchus to 1024s Internet poll, Hermes, Odin and Wotan to 64s poll. So Bacchus may get a bigger offset, but should be lower jitter...
1700, 2003 Oct 25, Sat, left just Bacchus connected to the Internet servers, with Hermes, Odin and Wotan peering with each other and being served from Bacchus with one Internet as backup.
1050, 2003 Oct 25, Sat, made least-used interactive PCs the main peered Internet connected ones (Hermes and Bacchus) and the most heavily used PCs (Odin and Wotan) the LAN served peers. Resulted in more drift than I liked on Hermes.
0915, 2003 Oct 25, Sat, changed LAN PCs Odin and Hermes to 128 second poll
1000, 2003 Oct 18, Sat, removed ntp.blueyonder.co.uk from Odin and Hermes as it seemed to pull Hermes during the evening and night, and Odin wouldn't talk to it in any case (permanently in INIT).
1315, 2003 Oct 17, Fri, updated to NTP release V4.2.0, added ntp.blueyonder.co.uk to Odin and Hermes as it has now had the large offset removed
0830, 2003 Oct 04, Sat, set Internet facing servers to 512s poll to reduce Bacchus offset
1530, 2003 Sep 05, Fri, restored Odin as peer for Hermes - graphs showed no change.
2100, 2003 Aug 21, Thu, removed Odin as peer for Hermes - likely to be unreliable due to animations.
1010, 2003 Jul 23, Wed, updated to V4.1.80-rc1 from Terje Mathisen.
1330, 2003 Apr 24, added Odin/Hermes as peer pair, and Bacchus/Wotan likewise.
1700, 2003 Mar 20, Thu, installed DVB card in Hermes, timekeeping goes to pot!
1000, 2003 Mar 18, Tue, updated to V4.1.74 with the CMOS code present.
1550, 2003 Feb 18, Tue, updated all to V4.1.74.
1615, 2003 Feb 07, Fri, revert to 1024s poll on Internet facing servers for a test.
0840, 2003 Jan 29, Wed, V4.1.73 (dev) installed on PCs Odin and Hermes, 0945 installed on Bacchus and Wotan.
0845, 2002 Dec 19, Thu, Bacchus and Wotan changed down to 512s maximum polling (to reduce Bacchus' drift).
1000, 20002 Dec 17, Tue, Bacchus and Wotan synced to Internet servers, PC Hermes and Odin synced to Bacchus/Wotan with 64s maximum polling.
2340, 2002 Dec 12, power cut, all PCs rebooted. Power back at 0020 Dec 13
1345, 2002 Nov 08, Fri, all PCs synced to Internet servers.
1100, 2002 Nov 07, Thu, Bacchus and Wotan synced to Internet servers, and PC Hermes and Odin synced to Bacchus/Wotan instead of Bacchus alone.
1445, 2002 Nov 06, Wed, only Bacchus was left synced to Internet servers, and PC Hermes, Odin and Wotan were synched to Bacchus instead of Internet NTP servers.

NTP Notes

For my own system

External links

Official NTP documentation
Where to find NTP software
Meinberg Windows NTP package download (includes Windows installer which can be automated for hands-off install)
Meinberg free NTP Time Server Monitor (auf Deutsch)
The NTP Windows port from Terje Mathisen which I have used in the past

Hardware suppliers - in alphabetical order - vendor-supplied descriptions

Galleon Systems - Providers of NTP Servers for Time Synchronisation of computer networks
Meinberg - NTP Time Servers and innovative solutions for Time and Frequency Synchronization using GPS, DCF77 and IRIG
TimeTools - TimeTools provides accurate MSF DCF-77 and GPS NTP Time Servers for accurate network timing.

2.15.0

Tobias Oetiker <oetiker@ee.ethz.ch> and Dave Rand <dlr@bungi.com>