[ntp:questions] Reference clock driver for /dev/rtc
mlichvar at redhat.com
Mon Jun 28 09:18:56 UTC 2010
On Sat, Jun 26, 2010 at 03:07:33PM +0000, David L. Mills wrote:
> Another case in which the engineering model in Linux and NTP are not
> compatible. Neither is necessarily wrong, just different. The
> following issues are known to me.
> 1. The Linux kernel discipline code adapted from my Alpha code of
> the 1990s does not account for the frequency gain at other than a
> 100-Hz clock. With a 1000-Hz clock this results in serious
> instability. I pointed this out some years ago and it is a trivial
> modification, but so far as I know it has not been fixed.
I think this was fixed few years ago when the tickless mode was
introduced in the kernel.
However, current kernels have one compile time constant set
differently from the standard implementation, the PLL gain shift
(SHIFT_PLL) is 2 instead of 4.
BTW, on the clknetsim page I announced in my previous post there are
some tests done with both SHIFT_PLL constants.
> 2. The Linux adjtime mechanism inserts an extra pole in the impulse
> response, presumably to speed convergence when relatively large
> adjustments are made. This makes NTP unstable at the larger poll
> intervals when the kernel discipline is not in use. Both the kernel
> and daemon discipline loops are carefully designed according to
> sound engineering principles for optimum response, but the extra
> pole defeats the design.
In which Linux version was this or how large the adjustment needed to
be? I don't remember ever seeing it and the ntpd daemon mode works
fine as far as I can tell.
> 3. The calling sequence for the ntp_gettime() system call is
> incompatible with current use. As a result, access to the TAI-UTC
> offset by application programs is not available.
This probably won't be fixed as it would break glibc compatibility.
More information about the questions