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