[ntp:questions] very slow convergence of ntp to correct time.

David Woolley david at ex.djwhome.demon.co.uk.invalid
Sun Jan 20 12:47:08 UTC 2008

In article <Hiqkj.8953$yQ1.2617 at edtnps89>,
Unruh <unruh-spam at physics.ubc.ca> wrote:

> but the offsets are still over 100 times worse than I was getting with
> chrony. (Yes, I know, one suggestion is-- go back to chrony-- but the

Note that chrony seems not to have been updated for several years and its
knocking copy on ntpd refers to an obsolete version and isn't, I think,
entirely true even for that.  It has never been supported on this newsgroup,
and I'm not aware that its author has ever contributed here.

It's based on NTP version 3, but looks as though it has a completely
different local clock discipline algorithm.  The local clock discipline
algorithm is an appendix, and appears to be non-normative in NTPv3,
but there isn't enough information, in the documentation, to establish
whether the rest of it is compliant with the RFC.  It does look to be
rather more than the typical SNTP client, as it seems to support multiple
servers and seems to maintain a frequency correction.

I get the impression that it uses a statistics based, linear regression,
approach, rather than the engineering based, phase locked loop on in the
reference implementation, but again the documentation is not explicit
on that.

It's main claim to usefulness is for systems that only get occasional
and irregular NTP readings, particularly systems that are on dialup,
or which are primarily updated by wristwatch and eye.

> I would assume that ntp is giving these samples with long round trip very low weight, or even
> eliminating them.

Note: if these spikes are positive, they may be the result of lost ticks.

Pop corn spikes of less than 128ms are not ignored in the default
configuration.  If, as I suspect, you only have one time source, they
will get full weight (for multiple sources, I think delay may be used
to weight the contribution between different sources).

There are two possible approaches to such excursions.  It might be possible
to reduce the 128ms to whatever your 95 to 98 percentile figure is.  However,
I suspect that this will seriously compromise the ability to get initial lock
and to recover from major disturbances.

You could also use the huff and puff filter, if they are the result of 
asymmetric delays.  I'm not sure how well that works on short timescales and
whether it assumes a particular sense for the asymmetry.

More information about the questions mailing list