gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] [gpsd-commit-watch] [SCM] GPSD branch, master, updated. r


From: Gary E. Miller
Subject: Re: [gpsd-dev] [gpsd-commit-watch] [SCM] GPSD branch, master, updated. release-3.10-68-gb7c28ae
Date: Tue, 26 Nov 2013 17:03:54 -0800

Yo Greg!

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

> 
> "Gary E. Miller" <address@hidden> writes:
> >     Fix inane comment in ppsthread.c
> 
> inane borders on ad hominem.

I keeping with your comment that I removed.

> My characterization of the comment as nonsensical stands.

Because you fail to understand the goodness involved.

>  The code read
> 
>           /* on a quad core 2.4GHz Xeon this removes about 20uS of
>            * latency, and about +/-5uS of jitter over the other
> method */ memset( (void *)&kernelpps_tv, 0, sizeof(kernelpps_tv));

Yes.  And still valid today.

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

  The timestamp has already been captured in the
> kernel, and a few us of latency in fetching the already-captured
> timestamp is of no consequence.

No.  You misunderstand.  The latency difference is relative to the
TIOMCIWAIT timestamp, which is one or two order of magnitude worse than
the KPPS.

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

> It does make sense that the fact that time_pps_fetch doesn't wait on
> Linux (either - perhaps PPS_CANWAIT is not implemented anywhere) is ok
> because the edge was waited for with TIOCMIWAIT.

Yes, and for many more reasons, if we have TIOMCIWAIT, best to wait on
it.  One of which is that USB GPS have not supported KPPS on Linux.

> It is good that you clarified that the code wrongly assumes TIOCMIWAIT
> is always defined.

One thing I keep fixing and people that do not understand keep breaking.

> Rototilling to fix that will have to wait until
> post 3.11, because It's clearly going to be too disruptive.

Yeah, this is not the time to break again.

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

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

> But that's perhaps an artifact of a vast
> amount of code that logically should be ifdef TIOCMIWAIT and isn't.

No, the edge detection logic is very intentional.  Deal with one edge,
then go back to wait.

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.

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

Attachment: signature.asc
Description: PGP signature


reply via email to

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