On Feb 15, 6:04 pm, Unruh <[email protected]> wrote: > Hans =?iso-8859-1?Q?J=F8rgen?= Jakobsen <[email protected]> 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. Cheers, Dave Hart _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
