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

[Greg Troxel]

"Gary E. Miller" <address@hidden> writes:

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

That much is obvious, and the comment reads as being about setting the
timeout to 0, not about using time_pps_fetch.

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

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

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

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

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

Certainly RFC2783 pps and no TIOMCIWAIT has to work; that's the case on
FreeBSD and NetBSD.   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.

It should be pretty easy to add RFC2783 pps to usb serial on Linux.  I
was able to do that for NetBSD in under an hour.  I realize there is
still 1 ms of jitter, more or less, but it still seems nice to capture
the timestamp in the kernel.

pgptA4y6buPRb.pgp
Description: PGP signature