Re: [tip:timers/ntp] ntp: adjust SHIFT_PLL to improve NTP convergence

[Miroslav Lichvar <mlichvar@redhat.com>]

On Tue, Jun 02, 2009 at 02:20:39AM +0200, Ingo Molnar wrote:
> > Would this not be true already, because the convergence of Linux 
> > system suddenly became a lot slower in 2.6.19?
> >
> > Damned if we do, damned if we don't - except the new behaviour 
> > introduced by your patches is nicer.
> 
> Not just that - but there's calibration noise during bootup that can 
> cause randomly distributed recalibrations as well. So other hosts in 
> a mixed environment will see inconsistencies anyway, after every 
> bootup.
> 
> NTP is all about being able to be resilient against time noise and 
> being able to sync up to a common time base ASAP.

There has to be a compromise between frequency and offset noise. When
SHIFT_PLL is set to 2 the frequency noise will be higher and that will
have a negative impact on the long-term ability to keep the clock
accurate. The error will grow faster when network connection is
suspended.

The PLL response can be configured to be the same as the proposed
SHIFT_PLL 2 by decreasing the time constant value in adjtimex
structure, so I'd rather keep following the NTP specification and
control it from userspace if necessary.

As for the calibration issue, would it be possible to export the
information that an instable clocksource is used and when was the last
time it was calibrated? Then we'd know when the drift file should not
be trusted and let NTP calculate the frequency directly (it takes
about 15 minutes).

-- 
Miroslav Lichvar