Max offset for IPv6 is now much smaller


#1

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


#2

And sometimes it’s really bad.

But this is only for IPv6. The same host with IPv4 is quite nice.

// Hans


#3

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.


#4

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.


#5

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


#6

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 …


#7

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


#8

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


#9

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