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

[Eric S. Raymond]

Gary E. Miller <address@hidden>:
> > "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.

That doesn't make them "NMEA".  There is no NMEA of either 0183 or
2000 flavors going on anywhere near this feature.  And they do in fact
have to do with ntpshm.c; they're generated by a hook called in the
PPS thread.
 
> > 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.

The rest of current PPS is *not* broken.  I can build it and see it
running live on the GR601-W and on both USB and parallel ports on the
TCX0.  You're gaving some kind of strange port problem with headers,
but there is no call to talk as though the code is a pile of wreckage.

> Can you point me to a filename/?

ship_pps_drift_message() in gpsd.c.

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

I already had the thought that most those sections of the manual page
should move to this document; they've always been a bit out of place
where they are.

>                 A proper HOWTO might include how to setup ntpd or
> chronyd, but that is slightly out of scope for gpsd.

Out of scope for the gpsd man page, but in scope for this document.

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

I've actually already written this section.  You'll see it shortly.
 
> > 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.

OK.

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

Nobody does it right because the few of you who know the black magic
have never documented it.  So let's *fix* that, dammit.
 
> > 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.

OK, I'll remove that table then.  Done.

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

Please do.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

signature.asc
Description: Digital signature