Hal Murray <hmur...@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.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
