lockclock
Hal Murray
hmurray at megapathdsl.net
Sat Jan 12 07:19:05 UTC 2019
>> 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.
More information about the devel
mailing list