Re: [gpsd-dev] Meaning of negative PPS offset?

[Gary E. Miller]

Yo Eric!

Sorry, I've been reading this thread in reverse order.

What you see is a bug (or debouncer) in the USB driver.

This should be handled totally separately from generic PPS.

Except for the new PPS changes, which I have not had to review or test,
the PPS code has been hammered to death.  99.99% probability anything
you think is wrong in it is a failure of your assumptions, not a coding
error.

On Tue, 26 Aug 2014 07:39:52 -0400 (EDT)
address@hidden (Eric S. Raymond) wrote:

> There is a comment in ppsthread.c that reads:
> 
>              * FIXME! The GR-601W at 38,400 or faster can send the
>              * serial fix before PPS by about 10 mSec!
> 
> And, indeed, when I run gosmon live at 9600 on a GR-601W I observe a 
> small negative offset. At the moment I write it is -0.003518431.
> 
> This puzzles me.  It makes me fear we may have a design or
> implementation bug.

Nope.  USB driver implementation issue.

> The offset is the delta in fractional seconds between the clock time
> of the last PPS and the second part of the last GPS timestamp seen,
> minus one second.

I can't say about gpsmon, but not what we ship ntpd/chrony.  So this
assumption 0. is wrong.

> The assumption here is that the GPS reporting cycle looks like this:
> 
> 1. GPS top of second occurs.  GPS asserts PPS.

Yes.
 
> 2. gpsd fields the PPS interrupt and records the clock time it arrived
> to microsecond precision.

Nope.  Usually nanoseconds.

> 3. When doing 2, gpsd looks at the last timestamp received in the
> GPS datastream, assumes it went with the *previous* reporting cycle,
> and increments the second part by one second.  This is assumed to be
> the base clock second for the *current* reporting cycle.

Yes.
 
> 3. GPS computes a fix. 

Yes.
 
> 4. GPS ships the fix and a timestamp for this cycle.

Yes.

> 5.  Return to step 1.

Yes.
 
> What I don't understand is how, under these assumptions, the
> offset value can ever be negative.

Assumption 0. is wrong which easily leads to negative offset as 
given to ntpd/chrony.  Assumption 6 is that PPS and Serial data
proceed in sequence through the USB driver.  Assumption 7 is that the
new patches did not mess up anything.

> Can someone explain this, and what it means when it happens?  I
> want to document this in the Time Service HOWTO.

Explained?  I'd also like to see what you think you are seeing
to verify assumptions.

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