[ntp:questions] chrony and ntp comparison-- ADSL hookup
unruh at physics.ubc.ca
Tue Feb 19 17:11:20 UTC 2008
Bill Unruh <unruh at physics.ubc.ca> writes:
>I have now run some absolute time discipline tests using chrony and ntp
>The server is a GPS PPM disciplined clock using ntp. The client is a
>machine on an ADSL line. The round trip between server and client is about
>16ms, which is about 100 times longer than the round trip times used
>earlier in the previous tests I posted.
>In each case I run the GPS PPM to measure the offset of the computer clock
>vs the GPS (It is a parallel port interrupt routine which on each interrupt
>reads the system clock and saves it in a buffer readable from /dev/gpsint.
>Ie, I measure the system time each time it receives a pulse from the GPS
>Garmin 18LVC receiver. Since this has an mean accuracy of about 2usec, its
>noise is negligible.
>The mean in both cases is about -.3ms. Ie the adsl trip is assymetric as to
>outgoing and return but about .6ms.
>In the case of ntp the variance in the readings is about .32ms. For chrony,
>the variance is about .11 msec, 1/3 of the variance of ntp. This is in
>confomity with what I found for the client on the same subnet as the clock.
>Now, chrony is much more aggresive in decreasing the poll interval when the
>statistics gets bad, so the mean poll time for chrony was 36sec while for
>ntp it was 127 sec (in both cases minpoll was 4 and maxpoll was 7).
>Since the noise is dominated by the random transmission times, and not the
>frequency drift of the osillator in the computer, this should not make any
>difference. (the variations in the drift are about 1ppm, and in 128 sec,
>that is only .1ms ) However, I will alter chrony to make it less agressive in
>decreasing the poll interval, and I hope increasing its mean poll time. If that
>does not work I will set minpoll to 6 for chrony.
>However the indications are that chrony is again more accurate than is ntp
>in disciplining the clock.
>Note that seems a reasonably stringent test of the two programs in a situation in
>which the transmission noise dominates the error budget, rather than the
>frequency drift noise as in the test on the same subnet.
One more data point. I altered chrony not to be so ready to decrease the
poll interval when the jitter grows. In my current run of .6 days, chrony
has an average poll interval of 80 sec (minpoll 4 maxpoll 7) rather than
the 36 with the original version. (Note that the time averaged poll
interval-- ie if you took the poll interval at each second and averaged
those-- is 108 sec. Ie most of the time is at maxpoll of 128s)
In this case the variance of the chrony readings decreased slightly to 98usec from
about 112usec. As I expected increasing the number of readings ( which
decreases chrony's timebase over which it estimates the offset and slope)
actually makes things slightly worse, rather than better.
To summarize, chrony has a factor of slightly less than 4 better variance than ntp
in the offset of the computer clock as compared with "true time" ( A GPS
PPS receiver on the client machine). Both ntp and chrony are using as their server a GPS PPS
controlled system whose "error" is about 3usec, two orders of magnitude
less than than the variance produced by the ADSL delays.
Note that the local GPS on teh client is NOT used to discipline the clock
in any way. It is purely a measurement tool.
The GPS on the server and client are identical (both Garmin GPS 18LVC
running into the parallel port and triggering timed interrupts). They are
separated by 6km. horizontally and about 80 meters vertically.
It is interesting that both ntp and chrony agree that ADSL introduces about
a .3ms bias into the time. (Both agree that the computer clock disciplined
by both ntp and chrony via the adsl connection is about .3ms slow of true
More information about the questions