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