Hi Dave: thank you for the response. This might be due to the fact that I'm presently using tunneling via Hurricane Electric to get my IPv6 connectivity, since none of my local ISPs are quite ready yet.
Do you know of any IPv6 tools that would allow me to trace out the forward and backward routes separately to see the difference in paths? Traceroute6 on Ubuntu doesn't seem to give me that option. Best regards, Alexander Falk President & CEO Altova, Inc. www.altova.com www.xmlaficionado.com twitter.com/afalk This e-mail and any attachments are intended only for the person/entity to which they are addressed and may contain confidential and/or privileged material. If you received this in error, please notify the sender and delete the message. On Jun 30, 2012, at 5:03 , Dave Hart wrote: > On Fri, Jun 29, 2012 at 3:38 PM, Alexander Falk <[email protected]> wrote: >> Good morning: >> >> I have now experimentally enabled IPv6 connectivity for my network and added >> my Stratum 1 NTP server (a Symmetricom S200 with rubidium oscillator & GPS >> reference) with the new IPv6 address in addition to the current IPv4 >> address. However, I noticed that the clock error shown in the statistics is >> significantly larger for the IPv6 address: >> >> IPv4: 96.237.191.14 >> IPv6: 2620:fc:8000::200 >> >> As you can see in the charts, the clock error for IPv4 is typically showing >> as less than +/- 5ms with only few occasional spikes into the +/- 10ms band >> due to network latencies. By contrast, the IPv6 statistics seem to have a >> biased offset of -30ms and fluctuate at that level. >> >> However, since it is the same physical machine and a Stratum 1 server I know >> for a fact that it is accurate. Is this an IPv6 networking issue with >> routing or latencies? Or is the monitoring server for IPv6 working >> differently? > > It appears the IPv4 path between the monitoring server and your server > is roughly symmetric, that is, the delay is the same in both > directions. The IPv6 path appears to be substantially asymmetric, > which manifests as a persistent offset. I'd argue it's a problem, but > your ISP may disagree -- very few agreements promise symmetric > latencies off-net :) > > Cheers, > Dave Hart
_______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
