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

Unruh unruh-spam at physics.ubc.ca
Tue Jan 22 18:29:26 UTC 2008


"David L. Mills" <mills at udel.edu> writes:

>Guys,

>I haven't read every word on this thread, but all I can contribute is 
>that nothing reported here is anything like my experience here. Our 
>servers pogo.udel.edu and rackety.udel.edu are synchronized via GPS and 
>PPS. I invite the skeptics to peek at them from time to time. I describe 
>their behavior as like cats; most of the time they are quiet and gentle 
>at a few microseconds, but once in a whild they show a surge of ten 
>microseconds or more, especially after a power failure, which we do get 
>from time to time.

You can also peek at mine (string.physics.ubc.ca) on
www.theory.physics.ubc.ca/chrony/chrony.html




>There is a persistent report that appears as a low-frequency ringing 
>with more or less constant period. This would seem to suggest something 
>wrong with the discipline loop transient response. In the past the most 
>likely cause has been an ill-advised tinker with the Unix adjtime() 
>system call with the dubious purpose of reducing the time to slew the 
>clock over some range. This wrecks the transient response and easily 
>leads to loop instability. If you are using the kernel time discipline 
>and not adjtime() this is not an issue.

I use ntp with NO tinkering at all.  So if the problem exists it exists in
NTP 4.2.4


>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.)


>and smoothly amortize over several hours. Be sure to clamp the poll 
>interval to 64 s over that period. If it does something else, like show 
>an exponentially decreasing ringing. Go looking for trouble.

>As for "offset should be much larger than the error", be careful here. 
>By error I assume you mean what ntpq rv shows as jitter. The best case 
>is when offset is indeed less than jitter; if the error is much larger 
>than error, this suggests the frequency has surged and the time 
>constant/poll interval needs to be reduced. Watch the poll interval 
>behavior in the loopstats data.

>Dave

>David Woolley wrote:

>> In article <eI8lj.17461$yQ1.5617 at edtnps89>,
>> Unruh <unruh-spam at physics.ubc.ca> wrote:
>> 
>> 
>>>No, the offset is the value reported in loopstats.
>> 
>> 
>> Same thing.  If chrony is reporting the same measurements, neither set of
>> measurements is particularly valid.  You need to measure the actual
>> offsets, using something that has a repeatability a couple of orders
>> of magnitude better.  Certainly for ntpd, offset should be much larger
>> than the error, when locked.  Is the server running ntpd?
>> 
>> Anyway, as I said, arguing by proxy is difficult and I'm rather hoping that
>> Dave Mills will take over.  Certainly it is Dave Mills you have to 
>> convince if ntpd is going to change.
>> 




More information about the questions mailing list