REFCLOCK rises again

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> Eric said:
> >> 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.
> 
> > Maybe. The devil is in the details.
> > I expect some issues around Mode 6.  We'd still need to exchange control
> > packets with it to query and set clock variables. 
> 
> That's one of the details I'm willing to overlook.  I want ntpq -p to look the 
> same.

Yeah, well, maybe you're willing to overlook it, but *I* can't. That
requirement turns into architectural and implementation complexity
that I have to manage.  Ultimately those costs will be reflected
in downstream defect rates.

> What sort of details do you want to examine or change?

The two most obvious pain points here are the fudgetime variables.
Some refclocks set their own custom clock variables, as well; the
generic driver in particular, I think one other as well.

Either ntpq needs to talk to refclockd directly or the control/monitoring
channel needs to be routed through the pipe to/from ntpd.  Both options
have significant complexity costs.

> >> How do we get 2 processes to read the same data?
> > We don't. Why do you expect to need this? 
> 
> We need to be able to run gpsmon while it is feeding data to ntpd.  Replace 
> gps with your favorite refclock.

You'll have to say more, I can't unpack this.
-- 
		<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.