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
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.
PC |
Bits |
Sync |
Poll
Int. |
Note |
Kernel
Mode |
Averaged
Jitter
Before |
Averaged
Jitter
After |
Frequency
Before
ppm |
Frequency
After
ppm |
Delta
F
ppm |
Offset
Step |
Persist
Across
Reboot |
Comment |
Windows-8 |
Stamsund
(desktop) |
64 |
PPS |
16 |
|
? |
+8..+9.5 µs |
8.4..8.7 µs |
-6.7 |
-6.67 |
none |
none |
|
No change. |
Bergen
(portable) |
32 |
WiFi |
32 |
|
|
40..110 µs |
45..100 µs |
~-27.5 |
~-27.25 |
small |
~500 µs |
Y |
No change. |
Windows-7 |
Alta
(desktop)
|
64 |
PPS |
16 |
(1) |
Y |
~25 µs |
~30 µs |
+3.5 |
+32.5 |
+29 |
7 ms |
|
Offset visibly more variable (RMS went from
20 to 40 µs), jitter has increased by about 20%. |
Hydra
(desktop) |
64 |
LAN |
32 |
(2) |
|
1 ms |
1 ms |
+5 |
+53 |
+48 |
> +20 ms |
|
Unchanged apart from the offset step. |
Molde
(desktop) |
32 |
WiFi |
32 |
(2) |
|
2.5..4.9 ms |
1.8..2.5 ms |
+6 |
+53 |
+47 |
> +20 ms |
|
Offset & frequency a little more stable
after the change. |
Ystad
(portable) |
32 |
WiFi |
32 |
(2) |
|
~2.5 ms |
1 ms |
~+1 |
~+14.2 |
+13 |
+8.5 ms |
Y |
Offset & frequency more stable after the
change. |
Windows Vista |
Puffin
(desktop) |
32 |
WiFi |
32 |
(2) |
|
1.2..2.2 ms |
1 ms |
+4 |
+34 |
+30 |
+20 ms |
Y |
Offset more stable after the change, but
looks more like positive spikes rather a symmetrical distribution.. |
Windows-XP |
Feenix
(desktop) |
32 |
PPS |
16 |
|
Y |
4..4.5 µs |
4..4.5 µs |
-7.3..-6.0 |
-7.2..-5.8 |
+0.3 |
none |
|
No change. |
Narvik
(desktop) |
32 |
LAN |
32 |
|
|
12..23 µs |
15..27 µs |
+9.1..11.3 |
+9.4..+11.8 |
+0.4 |
none |
|
No change. |
Windows-2000 |
Bacchus
(desktop) |
32 |
PPS |
16 |
|
Y |
34 µs |
34 µs |
-8.1..-6.2 |
-7.7..-5.8 |
+0.4 |
+200 µs |
|
No change. |
Notes:
- This PC has NTP interpolation forced on by
NTPD_USE_INTERP_DANGEROUS=1 as this drastically improves the offset and
jitter performance.
- 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.
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).
PC |
Bits |
Sync |
Poll
Int. |
Kernel
Mode |
Averaged
Jitter
Before |
Averaged
Jitter
After |
Frequency
Before
ppm |
Frequency
After
ppm |
Delta
F
ppm |
Offset
Step |
Persist
Across
Reboot |
Comment |
Windows-7 |
Ystad
(portable) |
32 |
Inet |
Var. |
|
> 3.2 ms |
~1.1 ms
after 12 hours, 2.7 ms peak during intensive network activity |
+14.25..+14.6 |
+14.2..+14.25 |
None |
N/A |
|
Significant improvement in jitter and
offset variation. |
|