What does --disable-kernel-PLL do?
Hal Murray
hmurray at megapathdsl.net
Mon Nov 21 12:40:03 UTC 2016
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.
------
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.
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.
--
These are my opinions. I hate spam.
More information about the devel
mailing list