[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 mailing list