Re: [gpsd-dev] [PATCH] Time Service HOWTO: Clarify state of RFC2783 on NetBSD.

[Greg Troxel]

"Gary E. Miller" <address@hidden> writes:

> On Tue, 26 Aug 2014 19:21:22 -0700
> Hal Murray <address@hidden> wrote:

>> ntpd uses the RFC2783 interface.  There is no reference to TIOCMIWAIT
>> in the ntpd code.
>
> Confirmed, but then operating without RFC2783 does not work.

True, but I think that's just a result of "write to the standards and
expect people to implement them", and not having extra code for the
not-specified-anywhere TIOCMIWAIT.

>> The ATOM driver opens /dev/pps<n>.  If that's not the right device
>> you are expected to setup a link.  The NMEA driver
>> tries /dev/gps<n>.  Again, that's probably a link.  If that doesn't
>> work for the PPS stuff, it tries /dev/gpspps<n>.
>
> So the gpsd approach, when it works, is smarter as it finds the
> required device.  We could hard code something as a fallback, but
> how would we handle multiple GPS and dynamic ports?

I think gpsd's code for finding the device is fine, and works on both
Linux with the /dev/ppsN complexity and on systems where you just use
the serial fd (other branch of the ifdef, with one line of code).  ntpd
has an extra problem, as refclocks are specified by type and number,
totally separate from regular devices, whereas gpsd is starting
(usually) with a serial port.  So that explains why ntpd is looking for
/dev/pps, because it tends to look for /dev/gps or something to be a
symlink to the serial port also.

>> With RFC2783, the kernel grabs the timestamp at interrupt time.
>> Userland can ask for the latest one any time.  There is a sequence
>> number to detect duplicates.  ntpd polls every second.
>
> That could be a problem as some want to sample higher.  Which seems
> a bit pointless to me.  But we could just have ppsthread wake up
> now and then to check.  When TIOCMIWAIT is not present.

Exactly - I think that is what is needed.   Sampling every 100 ms
shouldn't really hurt, and should be plenty fast enough.  It seems to be
asking for trouble to make things run in arrears with all the cycle
detection stuff, even if it should work.

> Nope.  Here is how gopsd does it in ppsthread.c:
>
>     if ( 0 > ioctl(session->gpsdata.gps_fd, TIOCSETD, &ldisc)) {
>         gpsd_report(session->context->debug, LOG_INF,
>                     "KPPS cannot set PPS line discipline: %s\n",
>                     strerror(errno));
>         return -1;
>     }

That's part of the #ifdef linux code to find the /dev/ppsN, and won't
come into play at all on systems that didn't invent separate /dev/ppsN
devices.  But I don't see any reason to mess with the current linux code
in gpsd (to find /dev/ppsN), which by all accounts seems to work fine.

>>  Thus it depends on kernel
>> support for TIOCMIWAIT rather than RFC2783.  That may have changed in
>> the last year or two.
>
> No longer the case.

See my detailed note from reading today's git; it looks like TIOCMIWAIT
is still needed.

>> I have a note saying that TIOCMIWAIT doesn't work on NetBSD or
>> FreeBSD.  I can't find it in /usr/include on systems running the
>> latest release.
>
> Yup.

I believe that TIOCMIWAIT has never been implemented on NetBSD or
FreeBSD.

pgpP8McZyD46I.pgp
Description: PGP signature