Miroslav,
Changing the value of SHIFT_PLL from 4 to 2 makes the kernel discipline
behave quire differently than the daemon discipline. When switching from
one to the other, the result will be a serious transient. With a kernel
update interval of one second, this value violates the minimum delay
requirement of the feedback loop. The design was very carefully done
according to sound engineering theory and practice. The design insures
optimum rise time relative to the time constant along with a controlled
overshoot of about five percent. The change to SHIFT_PLL will compromise
the intended behavior. If you make changes like that, be sure someone is
around with knowledge of feedback control theory.
The frequency gain problem was reported some time ago and I provided a
simple fix which reduces the frequency gain by a factor of the square of
the ratio of the actual clock frequency to 100 Hz. It has nothing to do
with a tickless kernel.
The extra pole in the adjtime() emulation was reported to me some time
ago and might have since been removed. The result with the extra pole
will be underdamping at large poll intervals resulting in oscillatory
behavior. It is most serious where the adjtime() pole frequency is close
to the discipline poll frequency. If it makes any difference, SGI has
the same problem.
Linux users should be told the incompatibility with the
ntp_gettimeofday() call means the TAI-UTC offset feature provided by the
NIST leapseconds file and the Autokey protocol will be unavailable. This
is most important for NASA/JPL users when converting to and from UTC and
TAI and eventually to TDB for deep space missions.
Dave
Miroslav Lichvar wrote:
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.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
