Bill and John, To Bill: Once upon a time several reference clock drivers I wrote had their own idiosycratic PPS support. There are over forty now in the driver collection. Years ago I pulled PPS support from all the drivers I wrote in favor of the atom driver. Most drivers can be used with the atom driver; the NMEA driver does use the $GPGSA sentence presumably to police the PPS, but there is no evidence the other GPS drivers do. The SHM driver you cite does much the same thing as the atom driver to monitor the offset, but so far as I can see does not groom the signal itself. Years ago I accidently plugged a signal generator in the PPS and the kernl went nuts.
You have a flawed interpreation of the NTP algorithms with respect to the synchronization distance and selection threshold. There is no need to wait for one day in seconds. That went away with NTPv4. As for a sticky bit, that would not be hard to add once things like flag glut are overcome, but from my experience here I would not recommend it for use in a public server. It is not as simple as you think, as things like the syncrhonization distance have to be mitigated, etc. To John: I suspect you know that all LORSTA stations run by the Coast Guard include in the weekly announcement series a time-of-coincidence (TOC) second at which the epoch of the second is equal to the epoch of the GRI. My Astron LORAN-C receiver, which was modified by the Coast Guard, flashes a light at the TOC. The TOCs and the intervals between them vary up to several minutes depending on the GRI of the chain. I made provisions for the TOC in the LORAN-C receiver I built some years ago, but never completed the code to exploit them. Dave Unruh wrote: >j...@febo.com (John Ackermann N8UR) writes: > > > >>David Woolley wrote: >> >> >>>Unruh wrote: >>> >>> >>> >>>>I have now looked at the refclock_atom source and indeed, it demands that a >>>>prefer clocksource is available, and ignores the PPS if it is not. This I >>>>believe is a bug, or at least a design infelicity. You could either hack >>>> >>>> >>>I suspect the reasoning may be that both normally come from the same >>>radio clock which will free-run the PPS when it loses a signal, so that >>>detecting the failure of the NMEA data is the only way of telling that >>>the PPS data is unreliable. >>> >>> > > > >>More than that, some PPS sources don't have an accompanying timecode, so >>they need another source to provide the coarse time. This does cause >>some interesting design challenges because it makes the PPS reliant on >>an external source. >> >> > > > >>A couple of years ago I tried defining multiple prefer peers to improve >>the reliability, but never got that working in a reliable way. >> >> > > > >>I'd like to see one of two solutions: (a) the ability to define >>multiple prefer peers, such that failure of one would cause a switch to >>another; or (b) an option that would require an external sane source for >>initial sync, but once the time is known to the second, continue relying >>on the PPS even if the prefer server goes away. >> >> > >The second would be trivial to apply. Just stick in a flag which gets set >once the initial external source has converged to within .1 sec say, and >if set it stays set and the PPS source gets used if it is set. If you >really worry, you could augment the flag everytime the prefer peer was >unavailable ( resetting it every time it was) and not use PPS if that >counter got greater than 86400 say ( one day) This is about a three line >change to the atom driver. > > > > > >>BTW -- this is a real-world issue, at least for my definition of >>"world". Two of my NTP servers have this problem. One syncs from a >>Cesium atomic clock, and the other from a LORAN-C receiver. Both those >>sources provide PPS but no accompanying timecode. >> >> > >Use the shmpps code with the refclock_shm driver. It will wait until the >time source is reported to have an offset of less than .25 sec, and then >start the shm report of the PPS source. Thereafter it will continue to use >the PPS source as a normal source, which you can make the preferred source. > > > >_______________________________________________ >questions mailing list >questions@lists.ntp.org >https://lists.ntp.org/mailman/listinfo/questions > > _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions