[ntp:questions] Garmin 18 LVC: whether to fudge

Unruh unruh-spam at physics.ubc.ca
Mon Feb 16 23:40:24 UTC 2009


Dave Hart <davehart at gmail.com> writes:

>On Feb 15, 6:04=A0pm, Unruh <unruh-s... at physics.ubc.ca> wrote:
>> Hans =3D?iso-8859-1?Q?J=3DF8rgen?=3D Jakobsen <h... at wheel.dk> writes:
>> >There ARE asymetric delays even for ntp packets.
>> >For my 14M/1.5M VDSL line I see an offset of 7-800 microseconds:
>> > ntpq -p
>> > =A0 =A0 remote =A0 =A0 =A0 =A0 =A0 refid =A0 =A0 =A0st t when poll reac=
>h =A0 delay =A0 offset =A0jitter
>> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>=AD=3D=3D=3D=3D
>> >-ns.tele.dk =A0 =A0 =A0.GPS. =A0 =A0 =A0 =A0 =A0 =A01 u =A0 48 =A0 64 =
>=A0377 =A0 22.450 =A0 =A00.891 =A0 0.096
>> >-tix.ns.tele.dk =A0.GPS. =A0 =A0 =A0 =A0 =A0 =A01 u =A0 =A07 =A0 64 =A03=
>77 =A0 22.338 =A0 =A00.698 =A0 0.183
>> >-puma.tele.dk =A0 =A0.GPS. =A0 =A0 =A0 =A0 =A0 =A01 u =A0 19 =A0 64 =A03=
>77 =A0 27.048 =A0 =A00.784 =A0 0.145
>> >+GPS_HP(0) =A0 =A0 =A0 .GPS. =A0 =A0 =A0 =A0 =A0 =A00 l =A0 10 =A0 16 =
>=A0377 =A0 =A00.000 =A0 -0.776 =A0 6.230
>> >oPPS(0) =A0 =A0 =A0 =A0 =A0.1PPS. =A0 =A0 =A0 =A0 =A0 0 l =A0 10 =A0 16 =
>=A0377 =A0 =A00.000 =A0 =A00.012 =A0 0.015
>> >+GPS_ONCORE(0) =A0 .GPS. =A0 =A0 =A0 =A0 =A0 =A00 l =A0 =A08 =A0 16 =A03=
>77 =A0 =A00.000 =A0 =A00.035 =A0 0.006
>>
>> Something is really weird here. .776ms from a GPS refclock is horrible.
>> That is about a factor of 300 worse than you would expect.

>You misread.  -0.776 represents the timestamp of the line feed at the
>end of a GPS timecode line on the serial port.  The PPS refclock on
>the next line is likely associated with the GPS_HP above it.  In other
>words, ntp is configured to treat the HP GPS as two distinct
>refclocks, a serial GPS timecode producer which will get you to the
>right second, and a PPS source which will only become influential once
>the time is within, uh, a half second I believe.  On the other hand,
>the oncore GPS refclock on the last line is a monolithic driver
>providing serial timecode and PPS in one refclock, based on the
>offset.

.776 is far too short a time to be the packet receipt from a GPS serial
line. He may have fudged out much of the time, but packet lengths vary by
more than that. (4800BPS is about 2 msec per character).


>> In fact all of
>> your GPS refclocks show bad time What are you doing to your clocks?

And .012 ms from a PPS source is a long time and a big offset.

Ie, all of his GPS times are weird.


>There are only two GPSes represented by the last three lines.  All the
>positive 700-900 usec offsets are nearby stratum 1 NTP servers across
>the DSL divide, confirming the point that now matter now teeny your
>packet is, it still takes 10 times longer to ride upstream 1.5M than
>it does to ride downstream 14M.

I have no idea how you get that it is taking 10 times as long.

Note that I have tested ADSL link, and do not get such an assymetry.


>Cheers,
>Dave Hart




More information about the questions mailing list