How the KERNEL_PLL switch kills TESTFRAME
hmurray at megapathdsl.net
Wed Sep 28 22:09:46 UTC 2016
esr at thyrsus.com said:
> The big deal is that a build *with* KERNEL_PLL will generate adjtimex(2)
> events into the capture logs. A build without KERNEL_PLL won't. Neither
> kind of log will be replayable on the other kind of build.
I don't have time to help with this now.
I think you should keep working on TESTFRAME. At worst, we'll end up with a
Linux only version. We'll probably learn more.
Part of the problem is that we have a word tangle between my use of "kernel
PLL" and your use of "KERNEL_PLL". I was referring to the PLL option in the
Linux kernel that gets included when you say:
I have access to Linux, NetBSD, and FreeBSD. ntpd runs on all 3 and does
essentially the same thing. The key ideas are being able to adjust the clock
"drift" and being able to slew the clock.
I'll bet other major OSes have similar ideas. If not, there isn't much ntpd
can do other than run in SNTP mode and step the clock occasionally. (That S
is supposed to be Simple. An alternative view is Stupid.)
The details on the interface to the kernel may be different for various OSes,
but the concepts mostly overlap. I think that's always been one of the rough
You said "adjtimex". There is also ntp_adjtime. It's available on Linux,
NetBSD, and FreeBSD. It's covered in RFC 1589.
The sandbox stuff knows about adjtimex but not ntp_adjtime, so I think we are
using the wrong API. There is either a good reason or a bug in the build
How well does it work if you build to use ntp_adjtime? Does that do
something silly like kill using the kernel PPS time stamping?
These are my opinions. I hate spam.
More information about the devel