An ideal world has no compatibility issues. This section deals with known incompatibilities.
6.4.1 The Kernel PLL
22.214.171.124 How many different kernel models and implementations exist?
126.96.36.199 What’s new in each Version?
188.8.131.52 Are the individual kernel models compatible?
184.108.40.206 Is the Linux implementation different?
There are two major versions for the kernel PLL: the model for NTPv3, and the model for NTPv4.
The history of the earlier kernel clock models is somewhat obscure. The basic features are described in Q: 220.127.116.11.
The clock model designed for NTPv4 has these features:
STA_MODE, controls a hybrid PLL/FLL mode, avoiding instabilities.
constanthas an incompatible meaning.
Revision 3 of the nanokernel introduced a shorter default calibration interval when correcting the frequency with PPS. At the same time the maximum interval can be adjusted using
MOD_PPSMAX. Selection of PLL and FLL mode is done automatically now.
Revision 4 of the nanokernel features more direct response to PPS offset errors, more realistic error estimates, and a new mode bit (
MOD_TAI) to define the offset between UTC and TAI.
A later revision featured a longer default calibration interval for PPS and a partial state reset when
STA_PLL is cleared.
The most recent version known as nanokernel has different semantics for the
time_constant. When used with the old version 3
xntpd daemon, the PLL has a tendency to oscillate, because the damping is too low.
When the old kernel implementation is used with the new version 4 daemon, the PLL is too stiff, causing a slow adjustment to frequency changes.
When the NTPv4 daemon sets the
STA_NANO bit, the old NTPv3 daemon gets completely confused by nanoseconds which are believed to be microseconds. As it seems, the daemon does not clear
STA_NANO during startup, so the only solution is to reboot or clear that flag by other means.
Professor David L. Mills wrote:
The old and new kernel code use different time constant ranges. The current
ntpd and API do understand and adjust accordingly. The old
xntpd will probably be off by a factor of 16 in the time constant. That is absolutely certain to cause unstable operation.
If you have an even older implementation, you probably can’t compile the daemon, or the daemon will not use the kernel PLL.
Yes, it is. One reason is that the original nanokernel was found to be broken with respect to
STA_PPSWANDER. According to Professor David L. Mills the current nanokernel is no longer showing that defect:
Professor David L. Mills wrote: “
MAXWANDER is 100 in the current nanokernel, not 500. This value was adjusted due to simulation experience.”
When used with a PPS signal, the Linux implementation (as of PPSkit-0.7) also computes uncommon values for
tolerance as I explained to Professor David L. Mills:
Another feature is that the maximum error is limited in Linux: it’s either 16s or 2s, depending on your version of the kernel. Whenever that value is reached, the
STA_UNSYNC flag is set in the kernel clock.
Was this page helpful?
Glad to hear it!
Sorry to hear that.