[ntp:questions] Garmin 18 LVC: whether to fudge
unruh-spam at physics.ubc.ca
Wed Feb 11 23:59:01 UTC 2009
"Richard B. Gilbert" <rgilbert88 at comcast.net> writes:
>shane-dated-1234940584 at csy.ca wrote:
>> I'm using a Garmin 18 LVC connected using LinuxPPS with mostly good results.
>> I am curious about one thing though. The offset reported by the GPS18
>> differ from the public NIST servers by around 1.7-1.9MS. as shown in the
>> offset numbers of ntpq below.
>> remote refid st t when poll reach delay offset jitter
>> *GPS_NMEA(0) .GPS. 0 l 4 16 377 0.000 -0.448 0.189
>> +bigben.cac.wash .USNO. 1 u 34 1024 377 11.134 0.283 2.645
>> All of the server's internet peers are ahead by around that same value so
>> I'm guessing that when the GPS18 loses sync, ntpd would have to bring the
>> clock up by 2MS and reverse when signal is reacquired.
>> Is there any way to know whether it's our internet link (ADSL) causing the
>> internet servers to appear off or does the GPS18 need a time1 fudge to bring
>> it in line with the others? That is, is there a 2MS lag in processing the
>> interrupt for PPS?
>My bet would be that there is an asymmetry in your ADSL link! If I'm
>not mistaken, the "A" in ADSL stands for asymmetric! Your GPS PPS
>output is probably within 50 nanoseconds of the exact time! The process
>of getting that signal into your computer is going degrade the accuracy
>by an amount that is somewhere between difficult and impossible to measure.
No, it is not. Put out a signal on one of the parallel port pins, and run
that into the whatever you use for the PPS input. read the system time when
you turn on the parallel pin and when the interrupt is read on the PPS
input. Subtract. On my system this is from 1-3usec, most usually 1.
Note that this is measuring the time required to switch on the parallel pin
as well as getting the input from the PPS pin, so it overestimates the
More information about the questions