[ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)

Unruh unruh-spam at physics.ubc.ca
Tue Jan 22 23:34:04 UTC 2008


"Maarten Wiltink" <maarten at kittensandcats.net> writes:

>"Unruh" <unruh-spam at physics.ubc.ca> wrote in message
>news:aCqlj.12849$vp3.7702 at edtnps90...
>> "David L. Mills" <mills at udel.edu> writes:

>>> There are lots of ways to measure the loop transient response. The
>>> easiest way is to set the clock some 50-100 ms off from some stable
>>> source (not necessarily accurate) and watch the loop converge. The
>>> response should cross zero in about 3000 s and overshoot about 6
>>> percent
>>
>> 3000 s is a HUGE time. For people who switch on their computers daily,
>> that means most of their time is spent with the computer unsynchronised
>> to best accuracy. The timescale of chrony is far faster. (I am not a
>> writer of chrony.I am a user who is trying to get the very best out of
>> the timekeeping.)

>But NTP is from a time when people didn't switch on their computers
>daily. When NTP was young, dinosaurs walked the machine room and
>_you_ did _not_ get to decide when the machine on the other end of
>your terminal was rebooted.

Sure, but there is nothing about the input/output of ntp that determines
how the clock is disciplined. 

>NTP can, after weeks of training, teach a computer to keep time very,
>very well. As a result, it's less optimised for the other end of the
>spectrum.

Well, no. The key features of computer clocks is that they are NOT stuck
into sealed temperature controlled fascilities. They wander through the
real world getting buffeted-- losing ticks, Air Cond. failures, etc. The algorithm
must be designed to handle those things rapidly and well. Ie, the noise
model used has some problems-- it is not random uncorrelated noise at short
times, and 1/f frequency drifts at long time scales. It is burps and
glitches and correlated noise at all time scales. 

Note that on the machine I was testing NTP this morning, for no reason
whatsoever that I can see, the frequency suddenly jumped by .4PPM which
caused a .5msec jump (20 sigma) in the offset which still has not settled down, a
couple of hours later. Chrony on the other hand has seen lots of frequency
jumps on various machines, but the offset error created by that is only
about 3sigma. And because of chrony's terrible handling of the network
interface, it constantly has noise spikes, and yet chrony's clock control
(as measured by the offset scatter) is a factor of 2 better than NTP. 
Ie, I think that on a local network, with one computer driven by say a GPS
clock, acting as the server,  all of the computers on that network can consistantly have an error
of 10usec. And by that I mean off the shelf, store bought computers with
their lousy crystals. 

Ie, NTP does NOT teach a computer to keep time "very very well" ( By very
very well I mean on a real computer with all its burps, and I mean control
very close to the best one can do). IF one has a machine which has a
constant drift, or a drift which changes very slowly, plus random gaussian
noise, then yes, NTP would do very well. But I do not believe that is the
real world. 

Of course to some extent this is silly. Who the hell needs his PC clock to
keep time to usec accuracy? On the other hand, if one is going to do
something it is just as well to do it as well as possible. 


>Features like iburst and the drift file can get your clock synchronised
>to within a few milliseconds in less than a minute. If you want better
>than that, or you want it faster... don't turn your computer off.

Ah, no, I want a few usec, and NTP does not handle transients that well. 
Maybe in 1980 a few msec was "good enough" (it was actually fantastic).
 But why not push the envelope to see what the best we can do is in 2008.


>Groetjes,
>Maarten Wiltink





More information about the questions mailing list