[ntp:questions] Garmin GPS 18 LVC suddenly not syncing, leap?

Dave Hart davehart at gmail.com
Mon Nov 21 22:14:07 UTC 2011


On Mon, Nov 21, 2011 at 18:57, Pete Ashdown <pashdown at xmission.com> wrote:
> I've been running an NTP server off of a Garmin GPS 18 LVC for months.  None
> of the software was updated or changed, and suddenly it won't sync to the
> Garmin.  When I start it, "ntpq -p" shows this:
>
>     remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
>  ntp.mcast.net   .MCST.          16 u    -   64    0    0.000    0.000   0.000
> *GPS_NMEA(1)     .GPS.            0 l    5   16  177    0.000   -0.078   0.058
>  time-C.timefreq .ACTS.           1 u   51   64    3   34.329  989.656   0.332
>  india.colorado. .ACTS.           1 u   51   64    3   34.722  1012.81   0.256
>  ntp0.usno.navy. .USNO.           1 u   52   64    3  113.842  1007.53   0.116
>  ntp-nasa.arc.na .GPS.            1 u   46   64    3   19.804  999.029   0.077

Likely what changed is the offset of the NMEA relative to the PPS.
I'm betting you're actually using a GPS 18x LVC, and that its firmware
hasn't been updated to 3.70.  Versions prior to 3.30 were prone to get
wedged requiring weeks of power off to drain their NVRAM
capacitor/battery, or an exchange through Garmin.  Yet 3.30 through
3.60 also degraded the offset of the NMEA output relative to PPS,
sometimes pushing the EOL of NMEA sentence you're using past the
following PPS.  3.70 is the first one that fixes both issues, curing
the wedging bug and the sloppy NMEA timing bug.

Notice that in the startup billboard above, the network sources have
each been polled only twice, meaning their clock shift registers still
have 6 entries with dispersion of 16s (MAXDISPERSE in the ntpd source,
visible with: ntpq -c "rv &3" through ntpq -c "rv &6".  Also visible
in that output is the resulting peer rootdisp= variable for each.
Until that is dragged under 1s by more polls, none of the network
sources are believable and your GPS rules the roost, apparently using
PPS from the microseconds offset.  Which raises my favorite question:
which version of ntpd?  (ntpq -crv will say).  I'm guessing it's 4.2.4
or earlier from the * rather than o tally code for your PPS-enabled
GPS.  With that version, fudge time2 isn't used by NMEA -- fudge time1
is the offset fudge for both NMEA and PPS.

> After a couple minutes it shows this:
>     remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
>  ntp.mcast.net   .MCST.          16 u    -   64    0    0.000    0.000   0.000
> xGPS_NMEA(1)     .GPS.            0 l   16   16  377    0.000   -0.178   0.066
> -time-C.timefreq .ACTS.           1 u   43   64   17   34.006  989.736   0.153
> +india.colorado. .ACTS.           1 u   46   64   17   34.764  1012.71   0.110
> +tick.usno.navy. .USNO.           1 u   47   64   17  115.380  1007.88   3.442
> *ntp-nasa.arc.na .GPS.            1 u   38   64   17   19.760  998.908   0.143

As typical, when reach hits 17 (4 polls after startup) the network
sources' root dispersions have fallen under 1s and they are usable.
ntpd has categorized the NMEA refclock as a falseticker with the
intersection algorithm, and discarded time-C with the cluster
algorithm, leaving the last 3 as survivors and ntp-nasa the system
peer.  ntpd is working as designed here, as the network peers are all
in agreement your PPS is being associated with the UTC second after
the one it should be.  Change your NMEA fudge time1 to 0.6 and it'll
probably come around, or upgrade to the latest 4.2.6 release which has
a fix to NMEA from Juergen Perlinger to more cleverly associate the
PPS with the correct second.

> When I run "ntpdate -vd" from a client, I get a refusal that contains this:
> 198.60.22.240: Server dropped: Leap not in sync
>
> I setup a leap file on the server and it is being loaded:
> # ntpq -c "rv 0 leap,tai,leapsec,expire"
> leap=11, leapsec=200901010000, expire=201206280000

NTP overloads the leap= value, displayed in binary.  Any value but 11
indicates your clock has been synchronized.  10 and 01 announce a
pending leap insertion or deletion at the end of the current month.
00 announces no pending leap.  11 means never synchronized and
shouldn't be happening with a * shown in the peers billboard.
ntpdate's message comes from considering only whether leap=11 or some
other value -- loading the leapseconds file is good, better if it
actually schedules a leap second in the future, but doesn't affect
whether the value is unsynchronized (11) or one of the three synced
values.

> This is the Garmin section of my ntp.conf:
> ## LinuxPPS: GPS + PPS
> server 127.127.20.1 minpoll 4 prefer
> fudge 127.127.20.1 flag1 1 flag2 0 time2 0.600
>
> Still no dice.  Help please?

The use of time2 0.600 and my guess of your version suggests you might
have used documentation not matching your version.  Steve Kostecke has
gathered and published a number of interesting versions of the NTP
docs at http://doc.ntp.org/ for easy reference.

Cheers,
Dave Hart


More information about the questions mailing list