REFCLOCK rises again

[Hal Murray]

esr at thyrsus.com said:
>> 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. 

I don't understand.  All I was trying to say is that splitting out the 
refclock drivers to another process shouldn't make any difference that is 
easily visible.

---------

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

Sounds good.  I suspect the hard part will be coordinating 
start/stop/crash/recovery.

How do we get 2 processes to read the same data?

--------

[kernel PLL]
> This is an area I don't understand well. But I'm willing to learn.

ntpd is a PLL tuned for network time scales.  Ages ago, they put another PLL 
into the kernel.  It works off PPS with different tuning parameters.  It works 
significantly better.

I think we should be able to do as well from userland.  The idea is to get a 
wakeup from the PPS logic, grab the data, do the same math, then reach back 
into the kernel via ntp_adjtime.  With modern processors, that should be a 
tiny fraction of a second and thus very close to what the kernel would have 
done.



-- 
These are my opinions.  I hate spam.