Re: [gpsd-dev] [gpsd-commit-watch] [SCM] GPSD branch, master, updated. release-3.10-68-gb7c28ae

[Gary E. Miller]

Yo Greg!

On Tue, 26 Nov 2013 20:12:16 -0500
Greg Troxel <address@hidden> wrote:

> >> and because this is just prior to a call to time_pps_fetch, this
> >> still does not make sense.
> >
> > Sure it does, it means KPPS gives lower latency and less delay than
> > TIOMCIWAIT alone.  Trivially verifiable, thus beyond doubt as true.
> 
> That much is obvious, and the comment reads as being about setting the
> timeout to 0, not about using time_pps_fetch.

Yes, because some moved it.

> It would help if there were a comment explaining the
> TIOCMIWAIT/time_pps_fetch linkage, because neither I nor Eric realized
> it at first. 

Another change pushed.  Further ideas?

> >> So the comment does not make sense,
> >> and does not explain what's really going on.
> >
> > Sure it does, but once you actually understand what is going on feel
> > free to improve it. 
> 
> The notion that an explanation explains only to those who already
> understand is a bit problematic.

No, you misread me, only those that understand it should improve it.  The
problem is people think they understand, and 'improve' it.

> >> I'm surprised that waiting until both sequence numbers are non-zero
> >> caused problems (rather than just skipping the first edge).
> >
> > Because the edge detection logic only works on one edge a time.  By
> > collecting both edges, one was never seen and the code went into an
> > infinite loop.
> 
> Comments explaining the logic would help.  The comments that are there
> did not give me confidence.

Which is why I always ask the newbie to copntribute to the documentation
because haing read it hundreds of times it makes perfect sense to me, minus
the manglng that happens regularly.

> >> I don't
> >> see how the code that figures out which edge is desired when one of
> >> the timestamps is missing.
> >
> > Because it is impossible to know the pulse width without both edges
> > of the pulse.  So the condition is detected and ignored, hoping for
> > things to improve.  As a practical matter, it does not seem to
> > matter.
> 
> I see.  I expected the loop to just wait until there were two edge
> timestamps, and then things would be simple.

No, that makes it WAY less simple.  It used to work that way and is was
awefull.  What if the first edge is the right one and you need to go
back THREE edges to validate it?

> > But yes, the ifdef TIOMCIWAIT, a battle I keep losing.  Too many
> > people that can't or don't understand/test this code keep getting
> > their fingers in it.  So (almost) time to make just KPPS and no
> > TIOMCIWAIT work.
> 
> This is complicated, but many readers not understanding is to me a
> clue that it's underdocumented.

Some things you can never explain to a pig.  Given that only 5% of all
good programmers can ever grok threads that means 95% will never undertand
this code.

> Certainly RFC2783 pps and no TIOMCIWAIT has to work;

Not possibile for the Linux USB GPS case I previously mentioned.  Sometimes
you have the one, sometimes the other, and only rarely both.  To cover
the most ground gpsd need to support those 3 cases.

> that's the case
> on FreeBSD and NetBSD.

And since I do not have either I'll leave that to you.

>   And a good point that on Linux with RFC2783
> present, one still has to dynamically look for that vs TIOMCIWAIT,
> because some devices only support TIOMCIWAIT.

Yes.  Or maybe gpsd is not running as root and thus has no access to
KPPS.  And other OS I suspect.

> It should be pretty easy to add RFC2783 pps to usb serial on Linux.

Sadly, there is no one serial on linux, there are dozens.

> I
> was able to do that for NetBSD in under an hour.

If gpsd stops breaking maybe I would have the time to try.  Then spend
months getting it in the kernel. :-)

> I realize there is
> still 1 ms of jitter, more or less, but it still seems nice to capture
> the timestamp in the kernel.

Nice, yes, but pointless from an accuracy standpoint.

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