REFCLOCK rises again

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> 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.)

It'd need its own UDP port.

> 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)

OK, it's good news that this matches my understanding of what's going on.
I'm going to add it to the devel/tour.adoc document...done.

> 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.

I like Unix named pipes for this kind of scenario.  They're very
straightforward, no buffering or hidden magic, no interaction with the
network code (thus no possibility of remote exploits), and an ironclad
atomicity if you keep your writes 512 bytes or below.

> 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.

This is an area I don't understand well. But I'm willing to learn.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.