Thanks for the reply - that is very, very interesting… Nothing in our network has been found to be dropping NTP packets. My only guess is that it is upstream from us at our ISP 
1 Like
Months and months later IPv4 scores still dive and rise. Ipv6 holds stable.
Indeed! My server is still marked ‘rubbish’ most of the time. The beta system only shows LA now, so I can’t see the comparison with Zurich anymore either…
Another NTP server on Scaleway here.
I’ve done a packet capture and found that my server is correctly receiving requests and generating replies.
Traceroute:
Summary
Traceroute to 51.15.92.0
1 gw-b.develooper.com (207.171.7.3) AS7012 0.246 0.199
2 gi1-9.r01.lax2.phyber.com (207.171.30.13) AS7012 0.959 1.041
3 te0-1-0-7.r04.lax02.as7012.net (207.171.30.61) AS7012 0.878 1.042
4 te0-10-0-20.ccr41.lax04.atlas.cogentco.com (38.88.197.81) AS174 0.934 1.026
5 (154.54.42.101) AS174 0.975
5 be3360.ccr42.lax01.atlas.cogentco.com (154.54.25.149) AS174 0.785
6 be2932.ccr32.phx01.atlas.cogentco.com (154.54.45.161) AS174 12.690 12.856
7 be2929.ccr21.elp01.atlas.cogentco.com (154.54.42.66) AS174 20.730 20.718
8 (154.54.30.161) AS174 36.619
8 be2927.ccr41.iah01.atlas.cogentco.com (154.54.29.221) AS174 36.545
9 (154.54.28.129) AS174 50.894
9 be2687.ccr41.atl01.atlas.cogentco.com (154.54.28.69) AS174 51.077
10 be2112.ccr41.dca01.atlas.cogentco.com (154.54.7.157) AS174 61.901 61.741
11 be2807.ccr42.jfk02.atlas.cogentco.com (154.54.40.109) AS174 68.058 68.051
12 be2317.ccr41.lon13.atlas.cogentco.com (154.54.30.186) AS174 138.701 138.593
13 (130.117.51.42) AS174 145.275
13 be12194.ccr41.ams03.atlas.cogentco.com (154.54.56.94) AS174 144.952
14 be3434.rcr21.ams06.atlas.cogentco.com (154.54.59.50) AS174 146.587 146.624
15 online.demarc.cogentco.com (149.14.92.210) AS174 152.821 152.800
16 (51.158.8.25) AS12876 153.572
16 (51.158.8.168) AS12876 147.730
17 * *
18 * *
19 * *
20 * *
21 quicksilver.scw-ams.ifcfg.info (51.15.92.0) AS12876 152.322 154.670
Update: I came across this post and now the issue seems really strange. The author has two servers both in the same IP address block (and I believe they are both Scaleway?), and one of them has a bad score just like the rest of us, but the other one does not seem to be affected at all.
Update again: Traceroute to the “good” server seems to be completely different:
Summary
Traceroute to 51.15.241.78
1 gw-b.develooper.com (207.171.7.3) AS7012 0.242 0.166
2 gi1-9.r01.lax2.phyber.com (207.171.30.13) AS7012 0.644 0.606
3 te0-1-0-7.r04.lax02.as7012.net (207.171.30.61) AS7012 0.993 3.441
4 xe-0-1-0-30.r01.lsanca07.us.bb.gin.ntt.net (198.172.90.73) AS2914 0.688 0.676
5 ae-19.r00.lsanca07.us.bb.gin.ntt.net (129.250.3.235) AS2914 1.090 0.826
6 ae-0.level3.lsanca07.us.bb.gin.ntt.net (129.250.9.94) AS2914 0.764 0.907
7 * *
8 (212.3.235.202) AS3356 141.116 141.111
9 (195.154.1.119) AS12876 141.286
9 (51.158.8.180) AS12876 140.387
10 * *
11 * *
12 * *
13 * *
14 * *
15 * *
16 * *
17 * *
18 * *
19 * *
20 * *
21 * *
22 * *
23 * *
24 * *
25 * *
26 * *
27 * *
28 * *
29 * *
30 * *
Traceroute to the “bad” one, however, looks the same as that to my server.
Hi,
the mysterious thing is that both have ipv6 connectivity and the score is about 18.x
The “good” one lives in DC Paris
The “bad” one lives in DC Amsterdam
ps: i’m the author from the other thread
pps: the bad one is gone. I setup a new one in Paris - maybe this one is better
So it looks like routing problem between Scaleway DC AMS and LA monitor station now.
Maybe just the monitoring station in general. My New Jersey VPS in the USA and my VPS in Hong Kong both dip and dive.
Noah
https://logiplex.net
Scaleway used to have an issue on part of their network that corrupted the checksums on about 50% of outbound UDP packets. No joke.
For the person I heard about it from, Scaleway fixed it around September, but maybe other parts of their network are still affected.
I have done some test to my server from outside Scaleway, mostly NL/HK/US. In most cases there is no problem. Although on some of the test servers there are a few packets lost, it is not like the continued “i/o timeout” the monitor has seen.
An interesting thing is that I did not get any reply on one particular server in US, and traceroute to my NTP server on that machine shows almost the same route as from the monitor.
I am seeing this same behavior on a Digital Ocean server in NYC. It happened a few months back, and has now happened at least twice in the past 2-3 days. I joined the beta server pool and it’s happy as a clam. over a time period that the LA monitoring server was scoring my server around 0. Everything about the hosting network looks good to me, as does my server.
My NYC1 droplet’s IPv4 address’s score went as low as -76 yesterday. (It’s more or less okay now.)
https://www.ntppool.org/scores/159.203.158.197
I was able to confirm that the issue didn’t just affect the monitoring server. (But I didn’t entirely track it down, or report it to DigitalOcean.)
Edit: It has two IPv4 addresses in the beta pool. The non-floating IP maintained a perfect score.
https://web.beta.grundclock.com/scores/159.203.158.197
https://web.beta.grundclock.com/scores/159.203.186.41
My FR dedicated server with online.net (by scaleway) seems to have similar issues. Since it has the same configuration as my hetzner servers (which mostly keeps at score 20), I believe it’s hardly a configuration issue from my side.
https://www.ntppool.org/scores/62.210.205.24
It looks better than the above charts from scaleway VPS though.