[ntp:questions] Garmin 18 LVC: whether to fudge
davehart at gmail.com
Sun Feb 15 18:48:48 UTC 2009
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
> 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.
More information about the questions