[ntp:questions] Atomized NMEA using second numbering from other server
Terje Mathisen
"terje.mathisen at tmsw.no" at ntp.org
Sat Oct 15 12:58:43 UTC 2011
Miguel Gonçalves wrote:
> Hi Dave!
>
> 2011/10/14 Miguel Gonçalves<mail at miguelgoncalves.com>:
>> tock# /usr/local/bin/ntpq -p -c as
>> remote refid st t when poll reach delay offset jitter
>> ==============================================================================
>> oGPS_NMEA(0) .GPS. 0 l 5 16 377 0.000 -0.004 0.004
>> *ntp-p1.obspm.fr .TS-3. 1 u 54 64 377 50.254 -1.269 7.885
>> +ptbtime1.ptb.de .DCFa. 1 u 59 64 377 69.087 -0.863 11.519
>> +ntp1.oma.be .PPS. 1 u 64 64 377 60.841 1.052 8.067
>> +canon.inria.fr .GPSi. 1 u 58 64 377 54.529 -2.730 9.511
>> -ntp1.nl.uu.net .PPS. 1 u 54 64 377 58.920 3.072 1.294
>>
>> ind assid status conf reach auth condition last_event cnt
>> ===========================================================
>> 1 64946 974a yes yes none pps.peer sys_peer 4
>> 2 64947 963a yes yes none sys.peer sys_peer 3
>> 3 64948 9424 yes yes none candidate reachable 2
>> 4 64949 9424 yes yes none candidate reachable 2
>> 5 64950 9424 yes yes none candidate reachable 2
>> 6 64951 9324 yes yes none outlyer reachable 2
>
> The NMEA clock is being selected as a PPS peer and it was (last_event)
> a sys_peer. At the moment an Internet server is the PPS peer.
>
> When fiddling with another machine with a GPS clock last night I found
> out this morning that the clock was being considered a false tick:
>
> tock# ntpq -p
> remote refid st t when poll reach delay offset jitter
> ==============================================================================
> xGPS_NMEA(0) .GPS. 0 l 3 16 377 0.000 -0.003 0.001
>
> I decided to use NMEA for second numbering and the PPS driver for the
> PPS. I found out that the NMEA clock was showing a lot of jitter so
> NTP couldn't use NMEA for second numbering and was thus marking it as
> false ticker. So I added
>
> tos mindist 0.25
>
> to ntp.conf and it is now
>
> tock# ntpq -p
> remote refid st t when poll reach delay offset jitter
> ==============================================================================
> *GPS_NMEA(0) .GPS. 0 l 9 16 377 0.000 -9.147 8.775
> oPPS(0) .PPS. 0 l 8 16 377 0.000 0.001 0.002
>
> I did the same on the other machine (the one I reported earlier and
> that is a pool server) and I am getting the expected behaviour:
>
> tick# ntpq -p
> remote refid st t when poll reach delay offset jitter
> ==============================================================================
> oGPS_NMEA(0) .GPS. 0 l 9 16 377 0.000 0.000 0.004
> +ntp-p1.obspm.fr .TS-3. 1 u 4 64 377 44.041 1.249 3.316
> +ptbtime1.ptb.de .DCFa. 1 u 11 64 377 67.837 0.566 3.670
> -ntp1.oma.be .PPS. 1 u 9 64 377 53.601 4.567 5.302
> +canon.inria.fr .GPSi. 1 u 11 64 377 44.790 1.415 1.406
> +ntp1.nl.uu.net .PPS. 1 u 13 64 377 58.364 3.385 142.094
>
> By the way, why are servers that use GPSi or PPSa as the refid? I
> searched the archives and couldn't find an answer.
The refid is an arbitrary set of up to 4 ascii characters, each driver
has a default name, but this can be easily overridden:
fudge x.x.x.x refid 'XYZ'
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
More information about the questions
mailing list