[LinuxPPS] LinuxPPS, kernel 4.4, ntpd 4.2.8

[Joachim Fabini]

Dear linuxpps list members,

does anyone know of a successful deployment of LinuxPPS with newer
kernel (4.4), ntp (4.2.8px) and PPS over serial interface on x86-based
PCs? Or of any known issues that linuxpps has with such a configuration?

Background: A setup and configuration that has worked reliably over
years on several of our x86-64bit PCs running Ubuntu (12.04, 14.04, ntp
4.2.6) is refusing to synchronize to the PPS source on Ubuntu 16.04 with
ntp 4.2.8.

The GPS/PPS source is connected via the serial interface (ttyS4).
ppstest reports a correct source and outputs correct assert statements.
The custom-compiled kernel is running, relevant modules are loaded by
the kernel, so anything looks just perfect.

# /var/log/syslog entries
Jan 10 10:47:36 ms kernel: [    0.743545] pps_core: LinuxPPS API ver. 1
registered
Jan 10 10:47:36 ms kernel: [    0.743547] pps_core: Software ver. 5.3.6
- Copyright 2005-2007 Rodolfo Giometti <giometti at linux.it>

# Relevant modules
/usr/src/pps-tools$ lsmod |grep pps
pps_ldisc              16384  1
pps_core               20480  2 ptp,pps_ldisc

# ppstest output
/usr/src/pps-tools$ sudo ./ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1484067774.990946245, sequence: 4730 - clear
1484063087.002174282, sequence: 7
source 0 - assert 1484067775.990968062, sequence: 4731 - clear
1484063087.002174282, sequence: 7
source 0 - assert 1484067776.990928266, sequence: 4732 - clear
1484063087.002174282, sequence: 7

However, ntpd (4.2.8p4, compiled from source with all relevant switches
- identical to the configure/compile of 4.2.6 that worked) refuses to
accept NMEA PPS clocks:

Jan 10 18:13:05 ms ntpd[3984]: refclock_params: time_pps_kcbind:
Operation not supported
Jan 10 18:13:05 ms ntpd[3984]: GPS_NMEA(0) set PPSAPI params fails

relevant ntp conf entries (working for 4.2.6):
server 127.127.20.0 prefer minpoll 4
fudge 127.127.20.0 flag1 1 flag3 1 flag2 0 time1 0.0 time2 0.524

Spending some time on ntp sources reveals that the ntp developers
removed an if-conditional in the source ntp_refclock.c between ntp
4.2.6p5 and 4.2.8. And my guess is that this screws up all Linux
implementations with 4.2.8.

# ntp_refclock.c 4.2.6p5
1236> if (time_pps_kcbind(ap->handle, PPS_KC_HARDPPS,
1237>     ap->pps_params.mode & ~PPS_TSFMT_TSPEC,
1238>     PPS_TSFMT_TSPEC) < 0) {
1239>     if (errno != EOPNOTSUPP) {
1240>        msyslog(LOG_ERR,
1241>            "refclock_params: time_pps_kcbind: %m");
1242>        return (0);
1243>     }
1244> }
1245> pps_enable = 1;

# ntp_refclock.c 4.2.8p5
1252> if (time_pps_kcbind(ap->handle, PPS_KC_HARDPPS,
1253>     ap->pps_params.mode & ~PPS_TSFMT_TSPEC,
1254>     PPS_TSFMT_TSPEC) < 0) {
1255>    msyslog(LOG_ERR,
1256>            "refclock_params: time_pps_kcbind: %m");
1257>    return (0);
1258> }
1259> hardpps_enable = 1;

My first guess (confirmed by re-inserting the missing conditional into
4.2.8) is that the NTP developers have effectively dropped Linux PPS
support by removing the conditional statement. The LinuxPPS API reports
kcbind as not supported (it's optional and not implemented) but supports
the PPS functionality that is needed by ntp (unless NTP now effectively
relies on the existence of time_pps_kcbind, which seems to not be the
case). Which means that the EOPNOTSUPP if is badly needed.

Can someone familiar with LinuxPPS and/or ntp confirm this diagnosis? Or
disprove it? This means that ntp 4.2.8 _could_ provide PPS functionality
in theory but in practice it does NOT because a developer has decided
(for whatever reason that is not known to me) to remove a conditional.

thanks in advance,
best regards
Joachim