On Sun, 15 Feb 2009 10:48:48 -0800 (PST), Dave Hart wrote:
> 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.
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

_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.org/mailman/listinfo/questions

Reply via email to