Re: [gpsd-dev] PPS and privilege-dropping

[Gary E. Miller]

Yo Eric!

On Thu, 17 Oct 2013 15:56:19 -0400
"Eric S. Raymond" <address@hidden> wrote:

> Gary E. Miller <address@hidden>:
> > > I have tested with the GR601W, not running as root, over USB.
> > > Serial PPS works (I see PPS messages in JSON).  This means that
> > > it ought to be possible in general to hotplug USB devices
> > > delivering PPS and have them work, even well after gpsd has
> > > dropped root privileges.
> > 
> > Yes, but KPPS will not.  BTW, the PPS mmessages in JSON are NMEA,
> > and never found a good use for them.
> 
> "are NMEA"?  Sorry, I don't understand what you're trying to say here.

I guess we are at a disconnect.  The PPS essages in the JSON have nothing
to do with the ntpshm timekeeping mechansm.

> The JSON PPS messages were designed with a specific purpose in mind -
> to track the skew between NTP-adjusyed system clock and GPS+PPS time
> so Dave Taht and I can benchmark NTP.

Well, there you do.  Nothing to do with ntpshm.c.  I guess I should look 
at that as it is likely broken like the rest of current PPS.

Can you point me to a filename/?

> > > I think kernel PPS failing is tolerable because *serial* PPS
> > > works in the general case.  What is the functional advantage of
> > > kernel PPS over serial?
> > 
> > By 'serial' you mean basic PPS.  All PPS is 'serial' as it uses an
> > RS-232 control line to mark the edge of the second.  Kernel PPS
> > uses a kernel function to accurately timestamp the status change on
> > the PPS line.  Basic PPS has the kernel wake up the PPS thread and
> > then the PPS thread reads the current system clock.  Obviously and
> > as notedd in the code, having the kernel do the time stamp is lower
> > latency and less jitter.  That is about 20 micro Sec less latency
> > and +/- 5 mucro Sec jitter on one of my test systems.
> >
> > With KPPS it is very doable to get the system clock stable to +/- 1
> > micro Sec.  Otherwise you are lucky to get +/- 5 micro Sec.
> > Important to a time nut.
> 
> Can I talk you into drafting a HOWTO on time-nuttery with GPSD to be
> included in the documentation?  Just dump your brain; I'll polish the
> formatting and language and then you can check my edits.

See the current sections "USE WITH NTP" and "USE WITH CHRONY" in the
current gpsd man page.  A proper HOWTO might include how to setup ntpd or
chronyd, but that is slightly out of scope for gpsd.

I would also add the comments in ntpshm.c starting on lines 78 and 865.

The only thing missing would be some help on enabling KPPS in the kernel
and getting time_pps.h installed.

ckuethe could contribute info on how this all works with BSD.

> It should include the above two paragraphs. Also remarks on serial-PPS
> accuracy vs. USB accuracy - the latter is controlled by the USB
> polling interval and will be about one millisecond, with the jitter.
> being whatever USB's polling-interval jitter is.

Possibly, but some of that info is per device and belongs on the
hardware page.

> 
> Which, by the way, is why I'm not sure there's any actual point to
> trying to support kernel PPS for hotplugged devices. The reason:
> they're going to be USB, which means they have an intrinsic accuracy
> limit about five times larger than the difference between plain and
> kernel PPS.

Uh, no.  That is a limitation of USB 1.1, not of USB 2.0 or 3.0.

OTOH, part of the breakage of KPPS on USB is in the kernel driver and
out of our control to fix.  What needed to be fixed in gpsd was USB
basic PPS failing because of bad KPPS code.  Next time git head can
build I can test that to be sure it stays fixed.

> Still, if you think we absolutely need to do this, I could add an
> scons option to disable privilege-dropping.

No, just log messages so the uninitiated are warned.

> A brief tutorial on how to choose NTPd offset parameters would be good
> to have in the HOWTO, too.  Basically I want this to be a primer for
> the relatively ignorant - like, er, me.

One could argue that is out of our scope as it is in the ntp.conf
file.  Basically you get several good chimers and adjust fudges until
they all agree.  From what I can tel no one really does it right.

> Also I think the table of NTP offsets that's now on the hardware page
> should move to the HOWTO.

They are all junk.  If they were really known good, they should move
into the code.

For example, in driver_garmin.c, line 1228:

static double garmin_ntp_offset(struct gps_device_t *session)

> >ALL ntpd prefers root for initialization.  There is serious loss of
> >functionality when not initialized as root.
>
> The HOWTO should explain this.

Few will read the HOWTO, those that don't will ask for help on
gpsd-users and it is impossible to debug remotely.  Thus when
initialization is not done as root there should be a log message.

When gpsd builds again I can add suitable logs.

> There's a reference to it in a comment
> in ntpshm.c, but it didn't tell me eniough to understand *why*.

One very basic issue, is that the mechanism gpsd uses to communicate
to ntpd or chronyd differs depending on whether gpsd is root or not.

Note the code and coments in ntpshm.c starting on lines 190 and 664.

Or just search for all usage of getuid() in ntpshm.c

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

signature.asc
Description: PGP signature