On Mon, Nov 21, 2011 at 18:57, Pete Ashdown <[email protected]> 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 _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
