Re: [gpsd-dev] Disturbing numbers

[Eric S. Raymond]

Andy Walls <address@hidden>:
> 0. What program in gpsd generated the above time stamps?

gpsd.  They're the fields from the PPS message without the JSON syntax.
 
> 1. How is the clock being set and disciplined?  ntpd, chrony, eyeball &
> free-running, or custom utility and kernel PPS discipline?
> ntpd and chrony don't like jumps and will ponder jumps before reacting.
> The eventual reaction will usually be a slewing of the clock vs. a step
> of the clock.  (It's hard to force ntpd and chrony to jump.)

Whatever is done on a on a stock Ubuntu 13.10 without ntp installed.

I didn't actually realize ntp wasn't running.   I had to do a non-upgrade 
install last week after an attempt to upgrade to 13.10 failed, and
lost my ntp instance.  

Installing ntp now.  We'll see if that makes the time converge.

> 2.  What does ntpdate -q (of a trusted server) tell you about your
> system clock offset?  Is it 2 seconds off, or very close to UTC?

address@hidden:/home/esr/software/gpsd# ntpdate -q
 3 Nov 13:54:16 ntpdate[31037]: no servers can be used, exiting

address@hidden:/home/esr/software/gpsd# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 ntp1.Housing.Be 128.32.206.54    2 u   22   64    1   84.103   -2.491   0.000
 15.126.197.207  192.5.41.40      2 u   22   64    1   14.065    0.589   0.000
 tux.brhelwig.co 127.67.113.92    2 u   37   64    1   51.581    0.052   0.000
 vimo.dorui.net  208.90.144.52    3 u   37   64    1   16.588   -0.860   0.000
 golem.canonical 193.79.237.14    2 u   37   64    1  114.052   -7.414   0.000

> 3. If using chrony or ntpd, is the GPS or the PPS configured to be a
> reference clock that can be selected? 

I'm not using a local refclock yet.  Once I hack my way through the
rest of the buglist I'll do the Tinme Service HOWTO steps, taking
notes.
 
> 4.  Is this shortly after power on of the GPS?  If so, could it be the
> case that the GPS is using the wrong UTC-GPS time offset (leap-seconds
> correction) because the almanac hasn't been downloaded yet?  If the GPS
> is missing the last 2 leap seconds, it will be ahead of UTC by 2
> seconds.

I thought of this, but since I wasn't running ntp it follows that gpsd
cannot have been feeding it funky time.

And I see by running gpsmon that my offset from GPS time has dripped
to around 2mSec. OK, it was not having ntpd running.  We can scratch that
bug, then.

(File under "Why I wanted gpsmon to be able to see PPS".)

I do notice a curious thing, though.  While I've been composing this reply 
my PPS offset has crept up from 2 to 13 mSec, and seems to be steadily 
rising.  What does this indicate?
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>