[ntp:questions] timing issue with a HP 58534A
Dave Hart
hart at ntp.org
Sat Feb 4 05:00:02 UTC 2012
On Sat, Feb 4, 2012 at 03:04, Mark C. Stephens <marks at non-stop.com.au> wrote:
> I put that in because without noselect I get this:
>
> [root at NTP ~]# ntpq -p
> remote refid st t when poll reach delay offset jitter
> ==============================================================================
> xGPS_NMEA(0) .GPS. 0 l 4 16 377 0.000 0.931 0.012
> xtime.non-stop.c 210.9.x.x 2 u 61 64 377 0.340 -496.02 0.236
>
> [root at NTP ~]# cat /etc/ntp.conf
> #
> #keysdir /etc/ntp
> keys /etc/ntp/keys
> trustedkey 1
> requestkey 1
> controlkey 1
>
>
> # GPS NMEA
> server 127.127.20.0 mode 16 minpoll 4 maxpoll 4
> fudge 127.127.20.0 flag1 1 # time2 -0.400
>
> # GPS PPS
> #server 127.127.22.0 minpoll 4 maxpoll 4 prefer
> #fudge 127.127.22.0 flag3 1
>
> #Inhouse reference
> server 192.168.5.8 iburst maxpoll 9
>
> logconfig =allall
> driftfile /etc/ntp/drift
> enable stats
> statsdir /var/ntp/stats
> statistics loopstats peerstats clockstats
>
> Both are now false tickers. Could it be this GPS gumming up the works?
It appears despite my claim, fudge time2 -0.525 or so is needed for
NMEA to properly associate the PPS with the correct second. Moreover,
you're running into the "man with two watches never knows what time it
is" problem -- there's no tiebreaker if there's disagreement. Add
more network sources, and/or "noselect" all sources except NMEA, at
least until you get NMEA behaving well.
Cheers,
Dave Hart
More information about the questions
mailing list