Jos vd Ven <[email protected]> writes: > This is the output of ntpq -p > > remote refid st t when poll reach delay offset jitter > ============================================================================== > o127.127.20.0 .GPS. 0 l 15 16 377 0.000 -0.001 0.002 > +193.190.230.65 .PPS. 1 u 52 64 377 14.094 1.934 0.570 > +193.190.230.66 .PPS. 1 u 2 64 377 14.585 2.141 0.610 > +193.79.237.14 .PPS. 1 u 64 64 377 10.131 2.372 0.512 > +192.87.36.4 .GPS. 1 u 15 64 377 11.980 1.815 0.556 > -192.87.110.2 .GPS. 1 u 38 64 377 9.901 -0.399 0.742 > +195.169.124.100 .PPS. 1 u 63 64 377 11.958 1.806 1.396 > +194.171.167.130 .PPS. 1 u 48 64 377 12.612 2.165 0.439 > *192.87.106.3 .PPS. 1 u 9 64 377 8.953 1.849 1.577
It's really hard to say. It does look like most of your peers are 2 ms ahead of your GPS. Likely explanations are: 1) Your internet connection has some sort of asymmetric delay. 2) Your ISP's peering introduces asymmetric delay. 3) The way your GPS is hooked up to ntpd introduces delay. Unfortunately these are all hard to debug. If you can traceroute to the various servers, and then from those servers traceroute back, and see if you spot anything odd, that can help. For example, I see paths from a Boston-area home ISP to a Boston office that go through NYC, but return paths that go through Atlanta. I see a persistent -11ms offset from a home server to one at work over v4, and over v6 I do not. I believe the v6 path (which involves tunnels) ends up being symmetric. In your case, though, the outlier has a much lower delay, with less opportunity for issues. But still, 7 ms and 3 ms half-paths will generate 2 ms of perceived offset.
pgpM0ZJYDiOgv.pgp
Description: PGP signature
_______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
