REFCLOCK rises again

[Hal Murray]

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

The fudgetime variables can remain in ntpd.

If the problem is the driver setting variables at initialization time, that 
should be easy to fix.  It's slightly more complicated to change things on the 
fly.  I'm thinking of things like up/down as the cable gets unplugged or the 
signal fades out due to rain.

Do you have an example of where we need to change a driver variable on the fly?

-------

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

I want to be able to run something like gpsmon while the driver is connected 
to ntpd.  If we use SHM, I know how to make the client side read only so we 
can have any number of clients.

I don't know how to do something similar with pipes.  I'm willing to do 
something like a TCP listener .  Maybe an internal SHM interface and a thread 
per pipe.

-- 
These are my opinions.  I hate spam.