Dear Community,
I realised that the maximum offset which is monitored is now much smaller since some days. This happens for all my IPv6 server but not for IPv4. ( Same server dual stack ) IPv6 server are now between +/- 1 ms. IPv4 is still between +/- 4 ms. I am here in Vienna/Austria. As there was no change on my side somewhere else something was changed.
Did anybody else see this improvement ?
Kind regards
Hans
And sometimes it’s really bad.
But this is only for IPv6. The same host with IPv4 is quite nice.
// Hans
so far i understand, there are many factors that impact the performance of IPv4 and IPv6 connectivity, starting with routing protocols.
because of dynamic routing protocols, sometimes the traffic between the monitoring station in LA, California may change its route, and hence the stability of the link may vary, providing sometimes higher timing jitter intervals.
i have noticed in the last days the IPv6 offsets are more stable and it could be due to an improvement of IPv6 protocol in the US in LA, or in the data center of the monitoring station, or because of an improvement of a contributor of the NTP pool project.
It’d be curious to see traceroutes when it’s good and bad. (To do traceroutes from the monitoring system you can use the http traceroute API.
Here are the traceroutes when it’s good.
Maybe I can catch it during a bad situation within the next days.
# curl http://trace.ntppool.org/traceroute/2001:628:21f0:80::80:35 Traceroute to 2001:628:21f0:80::80:35 1 (2607:f238:2::1) 0.555 0.539 0.654 2 (2607:f238:0:8::1) 1.057 1.056 1.044 3 (2001:504:13::1a) 11.372 11.113 11.110 4 10ge14-1.core1.den1.he.net (2001:470:0:15d::1) 27.281 27.019 27.243 5 100ge14-1.core1.mci3.he.net (2001:470:0:204::2) 39.264 40.288 39.247 6 100ge8-1.core2.chi1.he.net (2001:470:0:36c::2) 51.650 128.342 128.326 7 100ge3-2.core1.nyc4.he.net (2001:470:0:298::2) 68.229 67.976 67.971 8 100ge4-1.core1.par2.he.net (2001:470:0:33b::2) 139.143 139.820 139.817 9 100ge8-2.core1.vie1.he.net (2001:470:0:3f4::2) 157.542 152.917 154.244 10 * * * 0 12 vlan71.wien21.aco.net (2001:628:1000:1::2) 154.707 154.667 * 13 (2001:628:1101:1010::2) 155.760 154.715 155.495 14 (2001:67c:1b70:1000::2) 154.769 154.740 155.614
====
# traceroute 2607:f238:2::ff:5 traceroute: Warning: Multiple interfaces found; using 2001:628:21f0:99::99:154 @ net0:1 traceroute to 2607:f238:2::ff:5, 30 hops max, 60 byte packets 1 2001:628:21f0:99::99:1 0.725 ms 0.291 ms 0.236 ms 2 fxy.iiasa.ac.at (2001:628:21f0:125::125:90) 0.260 ms 0.226 ms 0.247 ms 3 2001:628:21f0:124::124:90 0.513 ms 0.482 ms 0.390 ms 4 2001:628:1101:1010::1 1.575 ms 1.604 ms 1.517 ms 5 bundle-ether-21-73.core21.aco.net (2001:628:1101:1::1) 2.108 ms * * 6 2001:7f8:30:0:2:1:0:6939 11.481 ms 12.382 ms 9.538 ms 7 100ge13-1.core1.par2.he.net (2001:470:0:3f4::1) 18.869 ms 23.020 ms 17.516 ms 8 * 100ge14-1.core1.nyc4.he.net (2001:470:0:33b::1) 95.432 ms 98.036 ms 9 100ge9-1.core2.chi1.he.net (2001:470:0:298::1) 104.312 ms 122.257 ms 104.291 ms 10 100ge12-1.core1.mci3.he.net (2001:470:0:36c::1) 116.673 ms 116.792 ms 116.735 ms 11 100ge12-1.core1.den1.he.net (2001:470:0:204::1) 129.119 ms 165.944 ms 128.910 ms 12 10ge13-1.core1.lax2.he.net (2001:470:0:15d::2) 161.383 ms 153.982 ms 164.839 ms 13 2001:504:13::210:50 156.379 ms 156.606 ms 157.774 ms 14 2607:f238:0:8::2 157.055 ms 156.801 ms 156.769 ms 15 manage.ntppool.org (2607:f238:2::ff:5) 156.795 ms !X 157.040 ms !X 156.875 ms !X
// Hans
One of the things that’d be fun to have would be an easy way to run traceroutes regularly and store them somewhere so we can compare over time …
Dear All,
Here we have the situation where offset goes down currently between -1 and -2 ms
# traceroute 2607:f238:2::ff:5 traceroute: Warning: Multiple interfaces found; using 2001:628:21f0:99::99:154 @ net0:1 traceroute to 2607:f238:2::ff:5, 30 hops max, 60 byte packets 1 * 2001:628:21f0:99::99:1 0.528 ms 0.424 ms 2 fxy.iiasa.ac.at (2001:628:21f0:125::125:90) 0.371 ms 0.249 ms 0.255 ms 3 2001:628:21f0:124::124:90 0.645 ms 0.463 ms 0.410 ms 4 2001:628:1101:1010::1 1.559 ms 1.538 ms 1.460 ms 5 * * * 6 2001:7f8:30:0:2:1:0:6939 1.992 ms 2.014 ms 1.795 ms 7 100ge13-1.core1.par2.he.net (2001:470:0:3f4::1) 23.980 ms 17.178 ms 18.706 ms 8 100ge14-1.core1.nyc4.he.net (2001:470:0:33b::1) 96.043 ms 98.451 ms 87.712 ms 9 100ge9-1.core2.chi1.he.net (2001:470:0:298::1) 104.211 ms 104.283 ms 112.097 ms 10 100ge12-1.core1.mci3.he.net (2001:470:0:36c::1) 116.595 ms 121.502 ms 125.929 ms 11 100ge12-1.core1.den1.he.net (2001:470:0:204::1) 131.160 ms 128.929 ms 139.509 ms 12 100ge12-1.core1.lax2.he.net (2001:470:0:3fa::1) 159.062 ms 154.440 ms 154.368 ms 13 2001:504:13::210:50 155.723 ms 155.466 ms 155.860 ms 14 2607:f238:0:8::2 154.901 ms 155.176 ms 154.923 ms 15 manage.ntppool.org (2607:f238:2::ff:5) 155.020 ms !X 155.144 ms !X 155.039 ms !X
# curl http://trace.ntppool.org/traceroute/2001:628:21f0:80::80:35 Traceroute to 2001:628:21f0:80::80:35 1 (2607:f238:2::1) 0.685 0.659 0.786 2 (2607:f238:0:8::1) 1.113 1.096 1.083 3 (2001:504:13::1a) 2.590 2.549 2.564 4 100ge2-2.core1.lax1.he.net (2001:470:0:72::1) 3.540 3.503 3.499 5 100ge12-1.core1.ash1.he.net (2001:470:0:324::1) 59.348 59.345 59.579 6 100ge3-1.core1.nyc4.he.net (2001:470:0:299::2) 68.834 73.056 73.001 7 100ge4-1.core1.par2.he.net (2001:470:0:33b::2) 192.347 192.051 192.323 8 100ge8-2.core1.vie1.he.net (2001:470:0:3f4::2) 153.243 153.395 153.393 9 * * * 10 vlan70.wien1.aco.net (2001:628:1100:1::2) 153.950 153.849 * 11 vlan71.wien21.aco.net (2001:628:1000:1::2) 153.570 * * 12 (2001:628:1101:1010::2) 155.038 154.796 154.650 13 (2001:67c:1b70:1000::2) 154.677 154.803 154.827
Path from monitoring to me is now different as in the good situation. But path from me to monitoring is identical as previously.
But RTT is almost the same.
Kind regards
Hans
both routes from the monitoring station to the NTP servers are different and according to my experience, we cannot guarantee each route to provide the same timing jitter.
timing jitter is something chaotic, unpredictable and unavoidable. one can only adapt to it and sometimes develop techniques for decreasing it.
each routing station has a fingerprint. there are many factors that impact on the performance of each station.
for example: the load of the routers, the cables’ length difference between two possible routes, temperature, software, hardware, etc.
accurate time measurement is kinda complicated. for example a stratum 1 server located in sydney, australia might offer to the monitoring station in los angeles a high timing jitter and then provide higher offsets. however it is possible that both share 99.999999% the same time.
maybe it would be ok to have a pool of servers monitoring other servers. for example my servers 1a.ncomputers.org 1b.ncomputers.org and 1c.ncomputers.org are located in germany and one of them could monitor other german IPv4 / IPv6 servers. then send the information to the monitoring station in Los Angeles, and using statistics provide more accurate scores.
in general terms, after researching about randomness i can apport that all hardware has some kind of randomness, since there is a direct relationship between hardware (physical matter) and the quantum zero point energy.
information that could be useful to understand more about the randomness of timing jitter (additional to what you can find in wikipedia):
Definition of ubit (unpredictable bit)
True random number generator: pandom
Dear All,
Now the offset for IPv6 is permanently about -1.5 ms. ( For me in Austria ) This could be my fault too. I am running a DCF77, a GPS and an atomic rubidium stratum-1 server and theoretical all three could go wrong. So I compared with the “official” time provider in Austria and Germany. But I have only some ± 10-microseconds offset to them.
@ Oliver ( ncomputers.org )
I completely agree with you. There are a lot of situations which could be the reason for a higher offset. Allowing me to add some comments: I made the experience that different speed for upstream and downstream data will cause such an offset issue. This can be verified very easy with an ADSL line. I made some experiments and theoretical aspects and posted it on my blog.
http://blog.mayer.tv/2016/03/16/ntp-and-adsl.html
http://blog.mayer.tv/2016/05/02/ntp-and-adsl-part2.html
Have a nice day and accurate time
Hans
–
