gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gary E. Miller
Subject: Re: [gpsd-dev] [PATCH] Time Service HOWTO: Clarify state of RFC2783 on NetBSD.
Date: Tue, 26 Aug 2014 19:42:07 -0700

Yo Hal!

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

> 
> > But we'll add whatever you want to try for NetBSD.  If ntpd does
> > it, where should I look for that code? 
> 
> The ntpd PPS code is in ntpd/ntp_refclock.c

I'll look.

> I don't think ntpd does anything special in this area for NetBSD.
> 
> ntpd uses the RFC2783 interface.  There is no reference to TIOCMIWAIT
> in the ntpd code.

Confirmed, but then operating without RFC2783 does not work.

> 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?

> 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.

> There is another part of RFC2783.  It moves the whole PPL into the
> kernel. I've never understood why that is needed.

By several  removing the kernel/user and user/kernel context switched
the latency and accuracy are seriously improved.  Probably two deciaml
places depending on a bunch of factors like load and CPU count.

> It used to work on Linux.  I think it took a patch.  I forget.  Then
> somebody cleaned things up and the patch broke or that stuff fell
> through the cracks or something.  The timestamping part is now
> supported again.

Alsways worked for me, after the added it.

>  It uses/needs ldattach, and you have to set it up
> before starting ntpd with something like: ldattach 18 /dev/ttyS0 &
> which makes /dev/pps<n>

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 stuff all gets tangled up with the new systemd stuff.  I haven't
> seen a good description of how to cleanly start ntpd that uses PPS
> using systemd.  I start it from rc.local.  (I haven't looked very
> hard.)

I use Gentoo, no systemd in my life, yet.  As we ahve seen distros
never seem to get it right.

> If I understand things correctly, gpsd uses TIOCMIWAIT and grabs the
> time from userland as soon as it can.

Yes, that save a lot of cycles, except it uses the RFC2783 time if
availab le.

>  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.

> 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'll be happy to help test the new code.

We'll need a NetBSD coder first.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
        address@hidden  Tel:+1(541)382-8588



reply via email to

[Prev in Thread] Current Thread [Next in Thread]