NTP bug 2328 - Preliminary Test Results

Reference: NTP bug report 2328.  See: https://support.ntp.org/bugs/show_bug.cgi?id=2328
 

Provisional Executive summary

Timekeeping on Internet clients may be substantially improved by the proposed change, timekeeping on LAN-connected Windows-7 and Windows Vista client is improved slightly, and Windows 8, XP & 2000 are not excessively adversely affected.  The calculated drift value may be different and will cause an offset step during the changeover period of up to 6 hours.

Contents

• Discussion
• LAN-synced tests
• Internet-synced test

Discussion

The data in the tables below was derived from the loopstats for the PCs under test, and plotted with my NTPplotter program.

All PCs here are normally synced from local sources, and not Internet sources, with a fixed poll interval of 32 seconds (maxpoll 5).  However, for one test, currently in progress, one Windows-7 PC was synced purely to the Internet pool servers, with a variable poll interval.  This is a more typical client PC configuration.  Sync: there are four possible sync sources:

• PPS - A GPS receiver connected to the PC's serial port, with a PPS (pulse per second) signal being connected to the DCD line of the serial port.  Windows timestamps the first received GPS/NMEA sentence with the time of the DCD transition.
• LAN - The PC is using its RJ45 Ethernet connection to sync to the stratum-1 servers available on the LAN.
• WiFi - The PC is using a wireless connection to sync to the stratum-1 servers available on the LAN.
• Inet - PC connected via WiFi to just Internet servers, with the poll interval allowed to float up to 1024 seconds.  Results are comparing earlier measurements from October 2012 using ntpd 4.2.7p285 with ntpd 4.2.7p348 in January 2013.

Poll Int. - Poll interval is either 16 seconds for PPS-synced PCs, or 32 seconds for LAN-synced PCs.  For the Internet-only test, a floating poll interval from 64 seconds upwards was allowed, and that was almost always at 1024 seconds.

For PPS-synced PCs, whether a special Kernel Mode device driver was in use was noted.

The jitter recorded in the loopstats is subject to a 6-hour exponentially weighted moving average and recorded in the Averaged Jitter values below.

The field labelled frequency in the table below is the value which would be stored in the drift file.  As the frequency calculated with the patch is different, the offset must necessarily change while the new drift is being computed, and this results in an Offset Step followed by a decay towards zero over the next several hours.

A check was also made on three PCs to see whether the change persisted across a power-down reboot (Persist Across Reboot), in particular that the new drift value was correct and did not cause a large offset at startup.  The updated drift was retained in all three PCs.
 

Table of results - LAN sync tests

Notes:

1. This PC has NTP interpolation forced on by NTPD_USE_INTERP_DANGEROUS=1 as this drastically improves the offset and jitter performance.
2. These PCs have NTP interpolation forced off by NTPD_USE_SYSTEM_CLOCK=1, otherwise they sometimes start with and sometimes start without interpolation (which doesn't work as well on these systems).  The detection of the system characteristics can get confused at start-up.

Table of results - Internet only sync test

These results are comparing ntpd 4.2.7p285 in October 2012 with ntpd 4.2.7p348 in January 2013, so they are not strictly comparable, but I believe they give a good indication of the benefits to be had with ntpd 4.2.7p348.  For both tests, only Internet servers were used, and the poll interval was allowed to drift between 64 and 1024 seconds (as most clients would be configured).

 

Copyright © David Taylor, Edinburgh

@gm8arv on Twitter

Last modified: 2015 Jan 18 at 09:32