Outline ·
[ Standard ] ·
Linear+
Anyone Noticed That European Links Went Bad?, Latency >400ms (Update Aft 2 Mths Unrsv)
|
ChenKaiWen
|
 May 6 2024, 11:55 PM
|
|
QUOTE(dayojah @ May 6 2024, 09:37 PM) I see 290ms ping to the UK, 5ms to a software site in Switzerland that actually downloads at modem speeds. I have seen ISPs playing QOS games that give fast ping, while data is in a huge buffer queue My ping to raspberrypi.org is around 10-20ms.but the ping to downloads.raspberrypi.org is 280-320ms and 10-20kb/s while downloading. It’s just where the servers are hosted. There is no way the ping to Switzerland is 5ms. The ping from Penang to KL with TIME is already 6-8ms. |
|
|
|
|
|
ChenKaiWen
|
May 7 2024, 08:50 AM
|
|
|
QUOTE(haya @ May 7 2024, 08:11 AM) That's because raspberrypi.org is behind Cloudflare: CODE traceroute to 172.67.36.98 (172.67.36.98), 30 hops max, 40 byte packets
1 223.28.26.21 (223.28.26.21) 2.703 ms 1.749 ms 1.428 ms
2 223.28.26.153 (223.28.26.153) 1.551 ms 5.944 ms 2.088 ms MPLS Label=50089 CoS=0 TTL=1 S=1
3 223.28.43.29 (223.28.43.29) 1.796 ms 1.750 ms 2.111 ms MPLS Label=48701 CoS=0 TTL=1 S=1
4 223.28.52.58 (223.28.52.58) 1.523 ms 2.067 ms 2.239 ms
5 211.25.221.206 (211.25.221.206) 1.916 ms 2.190 ms 1.961 ms
6 172.67.36.98 (172.67.36.98) 1.640 ms 1.882 ms 1.613 ms raspberrypi.org may be physically hosted in Switzerland, but from a end user perspective they hit the closest Cloudflare edge node. While downloads.raspberrypi.org is still hosted in the UK/not behind a CDN/accelerator: CODE traceroute to 93.93.130.212 (93.93.130.212), 30 hops max, 40 byte packets
1 223.28.26.21 (223.28.26.21) 8.777 ms 0.879 ms 0.650 ms
2 223.28.26.153 (223.28.26.153) 1.894 ms 1.998 ms 1.741 ms MPLS Label=53148 CoS=0 TTL=1 S=1
3 223.28.47.197 (223.28.47.197) 1.775 ms 1.825 ms 1.679 ms MPLS Label=54206 CoS=0 TTL=1 S=1
4 223.28.43.66 (223.28.43.66) 8.356 ms 6.554 ms 6.532 ms
5 93.93.133.16 (93.93.133.16) 269.474 ms 278.646 ms 275.087 ms
6 93.93.133.1 (93.93.133.1) 259.456 ms 293.486 ms 290.318 ms
7 93.93.133.7 (93.93.133.7) 280.220 ms 299.905 ms 298.519 ms
8 * * *
9 * * *
10 176.126.240.9 (176.126.240.9) 287.220 ms 297.101 ms 297.247 ms
11 93.93.130.212 (93.93.130.212) 322.112 ms 316.210 ms 323.109 ms Ah forgot about cloudflare. |
|
|
|
|
|
ChenKaiWen
|
May 16 2024, 07:01 PM
|
|
|
QUOTE(petpenyubobo @ May 16 2024, 06:14 PM) Ooops no improvement yet with TIME? Most SG major carriers are already getting <220ms to Amsterdam today. It's normalizing now.  On TIME. Edit: Last time i download, was only getting 10kb/s. Now at least 1mb/s This post has been edited by ChenKaiWen: May 16 2024, 07:05 PM |
|
|
|
|
|
ChenKaiWen
|
May 16 2024, 10:28 PM
|
|
|
DataPacket Amsterdam  DataPacket Frankfurt  DataPacket Paris  OVH Roubaix Paris  For the most parts, I think fixed but some still affected |
|
|
|
|
|
ChenKaiWen
|
May 17 2024, 11:14 AM
|
|
|
QUOTE(rezzorix @ May 16 2024, 11:07 PM) Nothing changed.
I suggest not to just run adhoc pings and judge based on that.
Continuous, long-term monitoring of network latency and packet loss are better for analysis.
Regular ping commands provide only a snapshot in time. You're right. A large amount of data would be better than a small amount of data. I've already setup smokeping yesterday. » Click to show Spoiler - click again to hide... « |
|
|
|
|
|
ChenKaiWen
|
May 17 2024, 12:50 PM
|
|
|
Idk how much this matters but after doing a traceroute to those data center. I've noticed those with lower ping and much stable is routed through TATA(MY -> SG -> IN -> destination) while higher ping is routed through NTT(MY -> SG -> JP -> US -> destination)
|
|
|
|
|
|
ChenKaiWen
|
Jun 29 2024, 08:29 AM
|
|
|
I can see improvement in my graph but it’s still morning.
|
|
|
|
|
Quote
0.0227sec
0.47
6 queries
GZIP Disabled