See Marks recent message about whether the offset applies to the next or previous PPS. For the rest of this, I'll assume next since it's simpler to describe. We can discuss the other/harder case if you agree that the rest of this makes sense.
[email protected] said: > Your concept of 'real time' does not match mine. The correction message arrives before the PPS. What's not real-time about that? You don't need any data from the future. > Also, how does that get me to the gola of a good PPS to feed into the Linux > PPS kernel module? I doubt Linux would accept a patch to put gpsd, and > more, into the kernel to read GPS and adjust the PPS. You don't fix the PPS, you fix the software processing the PPS to use the offset. Assuming you are using gpsd, you fix the serial side of gpsd to save the offset and the PPS side uses that offset to correct the PPS offset and then pass the corrected value to ntpd rather than the raw value. Linux/ntpd actually has two modes of PPS processing. The normal mode is that ntpd tells the kernel how to adjust the drift and offset. In that case, the gpsd processing described above would work. There is another mode where the PLL is done in the kernal and ntpd sits off to the side and watches, mostly doing a sanity check. This option, NTP_PPS, is not included in most kernels since it conflicts with NO_HZ_COMMON which saves power. I haven't checked the code. ntpd has a refclock config option for the offset. If that works for the kernel PLL, then the latest sawtooth correction could be passed in each second. If that doesn't work yet, it would be a small kernel mod to fix. -------- Another option would build some hardware to apply the correction. See Mark's recent message and/or the archives. There are chips that do the adjustable delays. -- These are my opinions. I hate spam. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
