[ntp:questions] Garmin 18 LVC: whether to fudge
Hans Jørgen Jakobsen
hjj at wheel.dk
Sun Feb 15 23:11:14 UTC 2009
On Sun, 15 Feb 2009 10:48:48 -0800 (PST), Dave Hart wrote:
> On Feb 15, 6:04 pm, Unruh <unruh-s... at physics.ubc.ca> wrote:
>> Hans =?iso-8859-1?Q?J=F8rgen?= 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
>> > remote refid st t when poll reach delay offset jitter
>> >==============================================================================
>> >-ns.tele.dk .GPS. 1 u 48 64 377 22.450 0.891 0.096
>> >-tix.ns.tele.dk .GPS. 1 u 7 64 377 22.338 0.698 0.183
>> >-puma.tele.dk .GPS. 1 u 19 64 377 27.048 0.784 0.145
>> >+GPS_HP(0) .GPS. 0 l 10 16 377 0.000 -0.776 6.230
>> >oPPS(0) .1PPS. 0 l 10 16 377 0.000 0.012 0.015
>> >+GPS_ONCORE(0) .GPS. 0 l 8 16 377 0.000 0.035 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.
>
>> In fact all of
>> your GPS refclocks show bad time What are you doing to your clocks?
>
> 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.
The difference are not that big for NTP packets over DSL for what reason I
have not dived into.
Assumming roundtrip to DSLAM are 20.6 ms and offset .75 ms gives up 11.05
and down 9.55 (roundtrip/2 +-offset)
/hjj
More information about the questions
mailing list