>> 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. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
