lockclock

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> >> If we are serious about supporting lockclock, we have to figure out a way 
> to
> >> test it.  We can probably make something that supports GPSDOs with PPS.
> 
> > That, on the other hand, seems to me like a good idea. But I don't have the
> > domain expertise to do it. 
> 
> Independent of the program structure, that's something I've been scheming on 
> for a while.
> 
> There are currently two ways for ntpd to use PPS.  One is via the PPS driver 
> or other drivers like NMEA that use the PPS when it works and the serial data 
> says things are good.  The other way is for ntpd to set things up then turn on 
> a status bit that tells the kernel to do all the work.
> 
> There is an optional PLL in the kernel.  At least in some cases, it works 
> better than ntpd.  I can't think of any reason that logic has to be in the 
> kernel.  The basic idea is that a PPS happens, then the data gets fed to an 
> algorithm which tweaks the clock. An extra ms to get PPS timing out to user 
> land and back in with new timing data shouldn't make a significant change to 
> the overall results and it gives us a good environment to experiment on.  That 
> wants a wakeup on PPS.  I think it's in the PPS API, but I don't know which 
> OSes implement it.  I'm pretty sure we can kludge something.

This is me being encouraging in your direction.  I'd be a bit out of my depth
doing 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.