What does --disable-kernel-PLL do?

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> I was expecting it to be a no-op unless you turned on one of the magic 
> options in a refclock that handed PPS processing off to the kernel.
> 
> I think it's doing more than that.  The symptom is that ntptime says:
> 
> ntp_gettime() returns code 5 (ERROR)
>   time dbdd51ae.aa8bc000 2016-11-21T02:57:50.666, (.666195),
>   maximum error 16000000 us, estimated error 16000000 us, TAI offset 0
> ntp_adjtime() returns code 5 (ERROR)
>   modes 0x0 (),
>   offset 0.000 us, frequency 0.000 ppm, interval 1 s,
>   maximum error 16000000 us, estimated error 16000000 us,
>   status 0x40 (UNSYNC),
>   time constant 2, precision 1.000 us, tolerance 500 ppm,
> 
> The long story is that I had a setup that included --disable-kernel-PLL.  (I 
> don't remember why I added that.)  I noticed that my daemon that records 
> things like CPU and disk temperature and NTP's drift was getting 0 for the 
> drift because that's what ntp_adjtime was returning.  I eventually tracked it 
> back to the --disable-kernel-PLL configuration option.

Here's the inside view from looking at the code: --disable-kernel-PLL turns
off the use of ntp_adjtime() to slew time, leaving adjustments to be done
at much coarser granularity by the old-style adjtime(2) call.

> There is a tangle in this area that I don't understand.  When ntpd exits (or 
> crashes), it leaves the previous state in the kernel so anybody running 
> ntptime will think things are fine.

What previous state?

> I think there is a minor bug in libntp/clockwork:ntp_adjtime_ns
> 
> The first time through when it tests for NANO/MICRO, it will get a wrong 
> answer.  See the sample above.  Here is printout from a debugging hack:
> 
> 21 Nov 03:30:13 ntpd[580]: ntp_adjtime: rc=5, modes: 0, status: 40
> 21 Nov 03:41:10 ntpd[1119]: ntp_adjtime: rc=0, modes: 0, status: 2001
> 
> The first line is from a reboot.  The second line if from restarting ntpd 
> after it had been running.
> 
> The code says:
>           nanoseconds = (STA_NANO & ztx.status) != 0;
> so the first run will work in MICRO mode and divide the time correction by 
> 1000.  But there is more code following that recomputs nanoseconds after each 
> call so it will get fixed before long.
> 
> It's probably a bug in the kernel that it doesn't return the MICRO/NANO flag 
> with the UNSYNC flag.

Yes, and it makes a fix difficult.  Do you have any recommended action?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>