[ntp:questions] Meinberg NTP monitor, silly question

unruh unruh at wormhole.physics.ubc.ca
Wed Dec 23 20:27:50 UTC 2009

On 2009-12-23, Richard B. Gilbert <rgilbert88 at comcast.net> wrote:
> unruh wrote:
>> On 2009-12-22, David Woolley <david at ex.djwhome.demon.invalid> wrote:
>>> David J Taylor wrote:
>>>> I do wish there were some way of speeding this up - a variable loop 
>>>> bandwidth or something like that.
>>> It already does have one, and has had one since at least version 3.
>> One problem ntp has its clock filter algorithm. It throws away 80% of
>> the incoming data. (It accepts a new reading only if that new reading
>> has a smaller delay than any of the last 8 readings. This effectively
>> means that the time between measurements is 8 times the poll interval.
>> Ie, if you have a poll interval of 6 (64 sec) the effective poll
>> interval for ntpd is 8 min. And at poll interval 10, the effective
>> interval is about 2 hr. the system certainly cannot respond to anything
>> more rapidly than that, and must do so more slowly in order to remain
>> stable. This is true even if the delay has a very small variance. 
>> Secondly because the only memory is contained in the rate, the system
>> has no way of actually estimating the rate of the clock with respect to
>> the remote clock. Ie, if the offset is positive, the rate is increased a
>> bit, if negative, it is decreased a bit, and that's it. But there is far
>> more information than that in the collection of offsets. With three
>> offsets, one can both estimate the drift, and the uncertainlty in that
>> drift. It is like walking down the street, staring only at i one square
>> inch of the the sidewalk
>> under your feet, and correcting when you see the curb in that 1 square
>> inch, and the grass, as opposed to looking ahead and behind you. 
>> Note that the time scales ( 1hr for halving the error) I mentioned is
>> for a poll interval of 4 (16 sec) .
> So, have YOU written a program that works better?  If so, why aren't you 
> using it instead of carping about the behavior of NTPD?

It is nice to have my claims to promptly and clearly substantiated.
No I have not write a program that works better. Richard Curnow did
about 12 years ago. And I do use it. This newsgroup is for discussion of
ntp, the protocol, not ntpd, the reference implimentation. And chrony,
the program Curnow wrote, is an implimentation of ntpd.

> Have you even modified NTPD to make it work better?  Tested your version 
> under a variety of conditions to demonstrate that it works better in all 
> reasonably probable circumstances?

The key bits of ntpd which are the filter and algorithm are claimed, in
no uncertain terms, by David Mills, and he refuses to countenance any
changes to them. 

I have tested chrony against ntp is a number of circumstances and shown
that it works better than ntpd. The results were posted to this news
group, where you can look at them at your leisure. they are not
exhaustive, and more work needs to be done. Some are also posted at 
www.theory.physics.ubc.ca/chrony/chrony.html.  However they are suggestive
( Much much faster convergence, smaller deviation from the "true time"
by factors of 2-3). Lichvar has also done some informal tests with
chrony and a gps refclock and has claimed much much better behaviour of
chrony (smaller standard deviation) over ntp. 
Are there situations where chrony works worse? I
would be interested to hear of them. 

> I didn't think so!

More information about the questions mailing list