[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