[ntp:questions] Reference clock driver for /dev/rtc
David L. Mills
mills at udel.edu
Mon Jun 28 17:29:49 UTC 2010
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.
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.
More information about the questions