I am quite confused by my current experience with ntpd and PPS (pulse-per-second) support in openSUSE 13.2, which is perhaps no different from other contemporary Linux-based systems, but far different from FreeBSD 10, which requires almost no efforts.
That is, with FreeBSD 10.0/10.1, all I needed to do was to recompile the kernel with PPS_SYNC option and then just configure ntpd (re-compiled with PPS/ATOM driver support) to sync to 127.127.20.0 with “flag1 1”, which means both NMEA sentences and PPS pulses from a GNSS receiver on /dev/gpspps0 which is symlink to the actual /dev/cuau0 serial port.
With openSUSE 13.2 and stock “desktop” kernel, all PPS and PTP timekeeping options are compiled as modules, so I manually loaded the pps_ldisc module (for serial ports), as well as other drivers and pps_core module. This, however, didn’t produce the desired effect, as ntpd still complained:
refclock_ppsapi: time_pps_create: Operation not supported
Digging into this, I found that there must be some PPSAPI testing tools in /usr/src/linux/Documentation/pps, but there were none, except the very same pps.txt file already found online; after checking the official source tree for all versions down to 2.6.32, it became apparent that these tools were never actually included in the upstream, although their accompanying pps.txt was. Nevertheless, it is easy to find 2 versions of pps-tools in the wild, but all of them still said:
# ppstest /dev/ttyS0
trying PPS source "/dev/ttyS0"
cannot create a PPS source from device "/dev/ttyS0" (Operation not supported)
Then I came upon instructions on LinuxPPS site which mention “ldattach 18 /dev/port” command needed to actually enable the PPS discipline on a serial port, and which creates /dev/ppsN device along with /sys/class/pps/ppsN pseudo-file tree. After that, I was finally able to launch ntpd, although in combo mode: with both 127.127.20.0 “flag1 0” and 127.127.22.0 “flag3 1”, which means that NMEA timecodes and PPS pulses are handled by 2 separate drivers, which need to employ fragile heuristics to function as one. NMEA driver then needs “time2 0.124” fudging to bring its timecode near the start of second (this is adjusted automatically when NMEA and PPS are configured as single source); otherwise this source will be considered falseticker that lags ~124 milliseconds behind all other known sources. And without an NMEA (or other preferred) source, PPS driver will never be selected, or will be deselected once NMEA source is unselected by clustering algorithm. To make things worse, both ntptime and ntpq -c kerninfo report kernel status as non-PPS:
ntp_adjtime() returns code 0 (OK)
modes 0x0 (),
offset 2.318 us, frequency 31.128 ppm, interval 1 s,
maximum error 6000 us, estimated error 1 us,
status 0x2001 (PLL,NANO),
time constant 4, precision 0.001 us, tolerance 500 ppm,
That is, ntptime output is aborted immediately before usual PPS stuff. Then I tried to relink /dev/gpspps0 to /dev/pps0 and configure ntpd as usual, but it seems that a Linux PPS device does not expose the underlying serial port, so that attempt failed. Retrying ppstest failed as well — unlike ppswatch (from alternative pps-tools pack), which started to print out timestamps (those are simply read from assert and clear pseudo-files in /sys/class/pps/ppsN).
To me, that makes PPS setup on Linux completely uncontrollable and undebuggable. Even if it actually works somehow (until the NMEA source is deselected sooner or later, also bringing PPS down with it), it can barely be considered a production-grade solution even at home. Thus I wonder whether I may be missing something obvious, and Linux indeed provides some trouble-free way to single-source NMEA+PPS, as I saw in FreeBSD. Do someone here have experience on that matter?
The pps_ldisc kernel driver for serial line discipline is completely GPS-agnostic and will work with any synchronisation pulse input fed to the DCD pin of a COM port. Moreover, the pps_core driver that stands above pps_ldisc is totally hardware-independent and is able to accommodate other PPS sources like pps_parport for the ACK pin of a parallel port — again, independently of any other information that may travel along this port on data pins.