ntpd 1PPS binding considered awful

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> esr at thyrsus.com said:
> > 1. The HOWTO recipe will switch to the gpsd+ntpsd method.  It's easier
> >    for kit-builders to understand.
> 
> I think that won't turn on the kernel PLL logic.

That...sounds like a very good point.  What *does* turn on the kernel
PLL logic?  Including refclock 22 in the build and config?

> This seems like a good opportunity for an experiment.  What do you have in 
> the way of a place to stand while can monitor other NTP servers?

The Pi might be it.  I have it set up to monitor four pool servers with
noselect.  I get output like this:

root at raspberrypi:/home/esr# ntpsec/build/main/ntpq/ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+SHM(0)          .GPS.            0 l   20   64  377    0.000  -532.74  49.431
*SHM(1)          .PPS.            0 l   22   64  377    0.000    0.971   0.014
 exposed.wfpadmi 104.131.51.97    3 u   25   64  377   51.241    4.174   2.886
 stratum-1.sjc02 .CDMA.           1 u   58   64  357   81.730    0.768   1.163
 ha1.smatwebdesi 199.102.46.77    2 u   42   64  377   40.919    3.054   1.277
 nox.prolixium.c 173.162.192.156  2 u   55   64  377   42.942   -1.597   0.805

Bearing in mind that I'm not sure what the units are (milliseconds?),
it looks like SHM(1) is tracking consensus time from the servers
pretty well (this is with a zero fudge).

What do these numbers say to you?

> > Splitting out refclockd has moved upwards on my priority list.
> 
> I hope you get TESTFRAME working first.  That would have caught the recent 
> leapfile mixup.

I'd like to do TESTFRAME first, yes.  That was always the plan. It has
proven so difficult that I'm now casting about for ways to simplify the
problem.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>