Mirslav,
There is a very good reason. First, the kernel can an only be switched
between PLL and FLL mode discreetly, while the daemon has a gradual
transition between modes so that the poll interval can vary seamlessly
between 8 s and 36 hr. Second, the kernel PLL is most useful to minimize
sawtooth errors, and is no better than the daemon loop to track
incidental frequency noise. Seldom if ever is it useful to switch to FLL
mode at poll intervals less than 1024 s, unless the incidental phase
noise is less than a microsecond.
It may happen that the kernel PLL switches modes occasionally during
operation at 1024 s, but that does not disturb timekeeping accuracy.
Recent versions of ntpd suppress log messages when switching modes like
that.
Dave
Miroslav Lichvar wrote:
On Sat, Oct 30, 2010 at 09:09:17AM -0700, Chuck Swiger wrote:
http://www.ece.udel.edu/~mills/database/papers/nano/nano.pdf
"In operation, PLL mode is preferred at small update intervals and
time constants and FLL mode at large intervals and time constants.
The optimum crossover point between the PLL and FLL modes, as
determined by simulation and analysis, is the Allan intercept. As a
compromise, the PLL/FLL algorithm operates in PLL mode for update
intervals of 256 s and smaller and in FLL mode for intervals of 1024
s and larger. Between 256 s and 1024 s the mode is specified by the
API. This behavior parallels the NTP daemon behavior, except that in
the latter the weight given the FLL prediction is linearly
interpolated from zero at 256 s to unity at 1024 s."
Is there a reason why ntpd doesn't make use of the STA_FLL flag? I
think it would be nice if ntpd switched the FLL limit to 256 s with
tinker allan 8 or lower.
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
