Re: [gpsd-dev] Disturbing numbers

[Andy Walls]

On Sat, 2013-11-02 at 02:10 -0400, Eric S. Raymond wrote:
> Here are some numbers I collected through a GR601-W while trying to
> write code to plot sytem clock difference from PPS. Columns are:
> 
> 1 Real second (GPS time of last PPS)
> 2 Real nanosecond (definitionally 0)
> 3 System clock second
> 4 System clock nanosecond
> 
> Yes, the same data as in the PPS JSON report.
> 
> 1383365763    0       1383365761      657868000
> 1383365764    0       1383365762      657867000
> 1383365765    0       1383365763      657869000
> 1383365766    0       1383365764      657868000
> 1383365767    0       1383365765      657865000
> 1383365768    0       1383365766      657867000
> [snip]
> 1383365789    0       1383365787      656873000
> 1383365790    0       1383365788      656875000
> 1383365791    0       1383365789      656877000
> 1383365792    0       1383365790      656878000
> 
> Either my system clock is off by two seconds or something is
> very wrong with our instrumentation.

0. What program in gpsd generated the above time stamps?

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

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?

3. If using chrony or ntpd, is the GPS or the PPS configured to be a
reference clock that can be selected?  For internet connected systems, I
would think you would want ntpd or chrony running with servers as the
only valid time sources (GPS and PPS refclocks marked with noselect or
whatever), when trying to collect data on the GPS unit.  Does the
'peers' command of ntpq show an 'x', indicating falseticker, in front of
the GPS or PPS timesource? (man ntpq and search for 'TALLY CODES' to see
what all the single character codes mean.)

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.

5. If you set the time with a custom utility or eyeball, make sure you
read the GPS time from shared memory and not over a TCP socket (i.e.
JSON) that does not have TCP_NODELAY set.  Even with TCP_NODELAY set,
you have to make sure your client has currently drained all the data
from the socket to get the latest timestamp, if you don't do something
like NTP does with multiple timestamps to measure delays in time
reports.

6. You might want to try using the 'sht' tool from the ntp distribution
to examine the data in the 'NTP[0123]' shared memory segments that GPSD
is generating.  I use the following patch to build sht when building
ntp:

--- a/util/sht.c        2013-07-25 11:36:06.533541865 -0400
+++ b/util/sht.c        2013-07-25 11:44:19.215037169 -0400
@@ -111,9 +111,10 @@ main (
        char *argv[]
        )
 {
-       volatile struct shmTime *p=getShmTime(2);
-       if (argc<=1) {
-               printf ("usage: %s r[c][l]|w|snnn\n",argv[0]);
+       volatile struct shmTime *p;
+       if (argc<=2) {
+               printf ("usage: %s <unit> r[c][l]|w|snnn\n",argv[0]);
+               printf ("       <unit>: shared memory unit number\n");
                printf ("       r read shared memory\n");
                printf ("        c clear valid-flag\n");
                printf ("        l loop (so, rcl will read and clear in a 
loop\n");
@@ -123,21 +124,22 @@ main (
                printf ("       pnnnn set precision to -nnn\n");
                exit (0);
        }
-       switch (argv[1][0]) {
+       p=getShmTime(atoi(&argv[1][0]));
+       switch (argv[2][0]) {
            case 's': {
-                   p->nsamples=atoi(&argv[1][1]);
+                   p->nsamples=atoi(&argv[2][1]);
            }
            break;
            case 'l': {
-                   p->leap=atoi(&argv[1][1]);
+                   p->leap=atoi(&argv[2][1]);
            }
            break;
            case 'p': {
-                   p->precision=-atoi(&argv[1][1]);
+                   p->precision=-atoi(&argv[2][1]);
            }
            break;
            case 'r': {
-                   char *ap=&argv[1][1];
+                   char *ap=&argv[2][1];
                    int clear=0;
                    int loop=0;
                    printf ("reader\n");
--- a/util/Makefile.am  2013-07-25 11:33:03.919726714 -0400
+++ b/util/Makefile.am  2013-07-25 11:35:23.589585746 -0400
@@ -4,10 +4,10 @@ AUTOMAKE_OPTIONS=     
 
 if NTP_BINSUBDIR_IS_BIN
 bin_PROGRAMS=  @MAKE_NTPTIME@ @MAKE_TICKADJ@ @MAKE_TIMETRIM@ \
-               ntp-keygen
+               ntp-keygen sht
 else
 sbin_PROGRAMS= @MAKE_NTPTIME@ @MAKE_TICKADJ@ @MAKE_TIMETRIM@ \
-               ntp-keygen
+               ntp-keygen sht
 endif
 
 EXTRA_PROGRAMS=        audio-pcm byteorder hist jitter kern longsize \




Regards,
Andy