REFCLOCK rises again

[Hal Murray]

My strawman for REFCLOCKD is something like the touring test.  You can't tell 
the difference by poking around with ntpq.  (Maybe you don't get to poke too 
deep.)

There are two parts to the refclock code.

The first operates on the second time scale.  The main thread calls the 
refclock receive routine when a "packet" arrives over the serial port and/or 
the timer routine every second so it can poll SHM and cleanup of the serial 
port gets unplugged.  That level of code puts samples into a FIFO.

The other is at the poll-interval level,16 seconds to 64 seconds.  That takes 
data out of the FIFO, discards outliers, averages, and injects a sample into 
the normal NTP processing pipeline where it shows up as a 1 bit in the peers 
reach mask.  (or a 0 if there weren't any good samples)

Currently, the SHM API is at the one second level.  ntpd gets a lot cleaner if 
we change that to the sample level.  We could provide something like the FIFO 
as a library package.

SHM may not be the right interface.  There is no way to get a wakeup when data 
is ready.  Maybe we should try a pipe or socket.  Maybe we should setup a 
thread to poll the SHM and set a flag and signal the main thread.

--------

That all seems reasonable to me.

There is one interesting area that it doesn't cover.  The kernel (on most 
OSes) has an optional PLL that locks on to a PPS source.  ntpd acts as a 
sanity check and turns that on and off.  If we want to use that mode, we need 
a back channel, or an ugly wart in ntpd.  We can probably get the back channel 
via ntpq.

That mode is not available on most OSes.  It's a build time option.  On Linux, 
it's not available if you want the power saving mode from the scheduler.  I 
should collect some data.

If we want refclocks in Go, we should probably prototype the ntpd side in c so 
we can debug the refclcocks and they will be ready when the Go version arrives.




-- 
These are my opinions.  I hate spam.