Here are just a few thoughts on using a 1 PPS hardware signal with ntpd.
Actually, if the so-called ATOM driver (driver 22) is used to handle a PPS source then in addition another refclock needs to be marked with the prefer keyword so that
ntpd can determine whether the time source is synchronized, or not, and thus the PPS signal should be used, or not:
Some refclock drivers (e.g the PARSE driver, driver 8) can be configured to evaluate the PPS slopes directly, i.e. the receive time stamp of a time string
know to be sent on a second boundary is replaced by the time stamp taken by the PPS handler, thus eliminating serial jitter.
In addition, particularly the parse driver supports the concept of a trust time, e.g. a time interval for which the source is still to be used after reception has failed.
Another approach is to let 3rd party applications like gpsd evaluate the PPS time stamps and feed the time stamps into ntpd
via the shared memory interface.
On some operating systems also the kernel PPS discipline can be enabled, so the OS kernel can directly evaluate the PPS slopes.
Windows doesn't support PPS input signals natively, but there is a workaround that provides limited support:
Programs like ntpd should control whether the PPS slopes can be used depending on whether the PPS source provides accurate time, or not.
Meinberg GPS receivers, for example, provide a high quality oscillator which is disciplined by the GPS/GNSS signal as long as reception is possible. In case reception fails, the time provided by the GPS receiver's disciplined oscillator (GPSDO) is still much more accurate than the system time of a standard PC which is driven by a cheap oscillator on the mainboard, so PPS discipline should be kept enabled in this case even after reception has failed.
On the other hand, there are cheap 3rd party GPS/GNSS modules out there where the PPS signal significantly starts drifting, immediately after reception has failed. If such a receiver is used then it makes sense to disable PPS discipline as soon as the GPS receiver has lost synchronization.
After power-up, the PPS signal is probably anyway inaccurate, so it makes sense to enable PPS discipline only after the associated time source has reached a certain level of synchronization and accuracy.
Unfortunately you can only mark a single time source with the prefer keyword, and even if you could mark several prefer sources that would be at least ambiguous.
Maybe a good way to solve this would be to support a way of doing the configuration the other way round.
Configure an atom driver and assign the pseudo IP of a refclock to it, e.g. using a fudge command or a keyword on the configuration line. This could tell the NTP kernel this PPS source is associated to that refclock, and it could evaluate the refclock sync status to determine whether the PPS source is freewheeling because the refclock fell out of sync, or not.
This would also provide a simple way to configure several PPS sources in parallel, each associated to the configured refclock.
And, if no refclock association is defined for a PPS source, ntpd could assume this is from an independent PPS source like a Rubidium or Cesium.
Note: This has originally been proposed in the NTP news group back in 2009:
— Martin Burnicki martin.burnicki@meinberg.de, last updated 2023-01-25