Hal Murray <hmur...@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>
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
