Ik ervaar het probleem dat ik erg lage download snelheden haal naar servers in de VS.
Ik heb hiervoor al een mail gestuurd naar de helpdesk, maar ze hebben het erg druk.
Ik vroeg me af of jullie misschien een idee hebben wat dit probleem zou kunnen veroorzaken.
Ik heb het een en ander geprobeerd, maar het had allemaal geen invloed op de snelheid.
Testen op een ander apparaat (laptop) met twee verschillende netwerkkabels
Netwerkkabel die Freedom had meegezonden en de netwerkkabel die in de FRITZ!Box doos zat
Ook andere poorten op de router geprobeerd.
Getest over IPv6.
Getest op verschillende tijdstippen op meerdere dagen, ook 's nachts en 's ochtends vroeg (rond 5:00-7:00).
DSL snelheid gecontroleerd, deze traint in op ongeveer 200 Mbps.
MTR laten lopen naar de verschillende hosts, maar er is geen packet loss te zien.
Verschillende servers gebruikt om te testen die allemaal via andere routes lopen.
Verschillende browsers gebruikt. Ook Windows Powershell geprobeerd voor het downloaden, maar daarmee haalde ik alleen maar lage snelheden.
De hosts die ik had gebruikt voor het testen waren onder andere:
Ik heb ook contact opgenomen met het hostingbedrijf van mijn server, maar zij konden niks vreemds zien in de route.
Mij was wel aangeraden om de Kernel te updaten en de Google congestie algoritme te gebruiken.
Hierna was de gemiddelde snelheid gestegen naar rond de 80-90 Mbps, maar ook hier heb ik dat ik dezelfde snelheidspatroon zie voor elke download.
Ook is me opgevallen dat het dus blijft steken rond de 80-90 Mbps wat heel dichtbij de 100 Mbps zit.
EDIT: Met iperf3 haal ik echter nog steeds een lage bandbreedte (14-15 Mbps). Hierbij had ik de instelling gekozen dat de server data stuurt en ik dat ontvang op mijn thuisverbinding. Dit in verband met de lagere uploadsnelheid bij mijn VDSL verbinding.
Het hostingbedrijf van mijn server vermoed rate-limiting, maar waarom dat zou voorkomen op het netwerk van Freedom is mij een raadsel. Daar doen ze volgens mij niet aan?
Als jullie meer informatie nodig hebben laat het me weten.
Klinkt als dat er een peering bottleneck is tussen Freedom en de VS.
Je zegt met VPN haal ik hogere snelheden, de peering tussen Freedom en je VPN provider heeft dus genoeg bandbreedte, en de verbinding tussen de VPN provider en de VS ook. Maar de directie verbinding tussen Freedom en de VS is geknepen om wat voor reden dan ook is dus de conclusie.
Ik hoop niet dat dat het geval is. De transitroutes van Fusix (upstream van Freedom) zijn wel gewoon goed in de zin dat de RTT normaal is en er geen packet loss is.
Het is in ieder geval beter dan wat er nu bij KPN gebruikt wordt.
Dat was voor mij ook een reden om daar weg te gaan.
Wat mij opviel is dat de snelheidspatroon precies hetzelfde was als bij KPN. Het lijkt mij teveel toeval dat ze bij Freedom ook dezelfde soort rate-limiting zouden gebruiken (als ze dat inderdaad doen)?
Dit probleem was in het verleden bij KPN verdwenen na een onderbreking van de DSL verbinding (vanuit KPN zijde).
Later weer teruggekeerd en ook dit was nadat de DSL verbinding verbroken was.
Ik zelf vermoed dat het probleem bij de wijkkast van KPN zou kunnen liggen, maar hoe zij de verbinding zouden kunnen rate-limiten ook al zit ik bij een andere provider is mij een raadsel.
Voor zover heb ik het alleen kunnen testen op mijn eigen internetverbinding.
Zouden jullie die testbestanden kunnen proberen te downloaden en kijken of jullie hetzelfde probleem met betrekking tot de snelheid hebben?
Bij DSL is de kans groot dat je nog steeds op een KPN kastje afgemonteerd bent, en dat alleen het VLAN omgehangen is van KPN → Freedom… KPN doet ook aan weder verkoop van verbindingen.
Omdat je download testen doet heb ik dat ook even gedaan:
(alle wired, 1Gbps glasvezel).
1e Naar disk: (mirror, sata).
firewall /tmp # curl http://nyc.speedtest.clouvider.net/1g.bin -o t.t
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1000M 100 1000M 0 0 5845k 0 0:02:55 0:02:55 --:--:-- 3908k
~5.8MB/s = 47Mbps netto data ~58Mbps line speed.
Tracing the path to nyc.speedtest.clouvider.net (94.154.159.137) on TCP port 80 (http), 30 hops max
1 lo1.cmbr.connected.by.freedom.nl (185.93.175.226) 0.669 ms 0.590 ms 0.629 ms
2 xe-1-1-0.core2.fi001.nl.freedomnet.nl (185.93.175.237) 0.676 ms 0.626 ms 0.635 ms
3 cr0.nikhef.nl.fusixnetworks.net (37.139.138.180) 0.666 ms 0.586 ms 4.376 ms
4 br0.drtam1.nl.fusixnetworks.net (37.139.139.247) 0.760 ms 0.780 ms 0.662 ms
5 adm-b1-link.ip.twelve99.net (62.115.151.184) 1.336 ms 1.381 ms 1.181 ms
6 adm-bb4-link.ip.twelve99.net (62.115.137.64) 79.514 ms 79.646 ms 79.777 ms
7 ldn-bb4-link.ip.twelve99.net (62.115.113.239) 20.236 ms 6.083 ms 6.402 ms
8 nyk-bb1-link.ip.twelve99.net (62.115.112.244) 80.506 ms 80.552 ms *
9 nyk-b3-link.ip.twelve99.net (62.115.115.9) 79.582 ms 79.734 ms 89.721 ms
10 clouvider-svc070131-ic355872.ip.twelve99-cust.net (195.12.254.199) 102.118 ms 75.136 ms 75.125 ms
11 62.182.98.18 75.585 ms 75.494 ms 75.724 ms
12 * * *
13 * * *
14 * * *
15 94.154.159.3 80.193 ms 80.282 ms 80.135 ms
16 94.154.159.4 76.047 ms 75.893 ms 76.671 ms
17 94.154.159.137 [open] 75.158 ms 75.316 ms 75.262 ms
Zelfde file naar Bitbucket: (wel OS overhead van schrijven).
firewall /tmp # curl http://nyc.speedtest.clouvider.net/1g.bin -o /dev/null # to bitbucket, stilll IO overhead...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1000M 100 1000M 0 0 11.0M 0 0:01:30 0:01:30 --:--:-- 18.4M
11MB/s ~ 88Mbps netto data ~110Mbps line speed
Idem andere site zelfde provider:
firewall /tmp # curl http://la.speedtest.clouvider.net/1g.bin -o /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1000M 100 1000M 0 0 6416k 0 0:02:39 0:02:39 --:--:-- 4519k
6.4MB/s ~50Mbps netto data ~64Mbps line speed
Tracing the path to la.speedtest.clouvider.net (77.247.126.223) on TCP port 80 (http), 30 hops max
1 lo1.cmbr.connected.by.freedom.nl (185.93.175.226) 0.569 ms 0.603 ms 0.582 ms
2 xe-1-1-0.core2.fi001.nl.freedomnet.nl (185.93.175.237) 0.683 ms 0.684 ms 1.148 ms
3 cr0.nikhef.nl.fusixnetworks.net (37.139.138.180) 0.679 ms 0.669 ms 0.676 ms
4 br0.drtam1.nl.fusixnetworks.net (37.139.139.247) 0.836 ms 0.701 ms 0.777 ms
5 adm-b1-link.ip.twelve99.net (62.115.151.184) 1.229 ms 1.151 ms 1.215 ms
6 adm-bb3-link.ip.twelve99.net (62.115.136.194) 151.292 ms 151.280 ms 151.407 ms
7 prs-bb1-link.ip.twelve99.net (62.115.134.97) 146.503 ms 146.103 ms 146.151 ms
8 ash-bb2-link.ip.twelve99.net (62.115.112.242) 91.651 ms 91.623 ms 91.824 ms
9 las-b22-link.ip.twelve99.net (62.115.121.220) 150.260 ms 149.906 ms 149.941 ms
10 clouvider-svc070132-ic355873.ip.twelve99-cust.net (213.248.74.63) 148.758 ms 148.912 ms 148.838 ms
11 77.247.126.1 148.087 ms 147.970 ms 180.002 ms
12 77.247.126.223 [open] 145.604 ms 145.612 ms 145.613 ms
Andere Provider in de US:
firewall /tmp # curl http://testfile.chi.steadfast.net/ -o /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 100M 100 100M 0 0 22.3M 0 0:00:04 0:00:04 --:--:-- 22.4M
22.3MBps ~178Mbps netto data, 223Mbps Linespeed
Tracing the path to testfile.chi.steadfast.net (208.100.4.54) on TCP port 80 (http), 30 hops max
1 lo1.cmbr.connected.by.freedom.nl (185.93.175.226) 0.623 ms 0.591 ms 0.607 ms
2 xe-1-1-0.core2.fi001.nl.freedomnet.nl (185.93.175.237) 3.083 ms 0.676 ms 0.637 ms
3 cr0.nikhef.nl.fusixnetworks.net (37.139.138.180) 0.664 ms 0.665 ms 0.681 ms
4 br0.nikhef.nl.fusixnetworks.net (37.139.139.233) 0.747 ms 0.706 ms 0.763 ms
5 speed-ix.zayo.com (185.1.95.14) 0.918 ms 0.731 ms 0.773 ms
6 * * ae11.cs3.ams10.nl.zip.zayo.com (64.125.31.104) 88.568 ms
7 * * *
8 * ae0.cs3.lhr11.uk.eth.zayo.com (64.125.29.118) 89.314 ms *
9 * * *
10 * * *
11 * * *
12 208.184.225.5.IDIA-308330-ZYO.zip.zayo.com (208.184.225.5) 88.134 ms 88.117 ms 87.978 ms
13 te8-4.dist02.chi01.steadfast.net (208.100.32.53) 90.357 ms 88.094 ms 88.066 ms
14 lookingglass.chi.steadfast.net (208.100.4.54) [open] 88.200 ms 88.342 ms 88.252 ms
Andere Site
firewall /tmp # curl http://testfile.edi.steadfast.net/ -o /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 100M 100 100M 0 0 20.1M 0 0:00:04 0:00:04 --:--:-- 22.8M
20.1MBps ~160Mbps netto data, 201Mbps Linespeed
Tracing the path to testfile.edi.steadfast.net (69.162.170.5) on TCP port 80 (http), 30 hops max
1 lo1.cmbr.connected.by.freedom.nl (185.93.175.226) 0.588 ms 0.556 ms 0.599 ms
2 xe-1-1-0.core2.fi001.nl.freedomnet.nl (185.93.175.237) 1.851 ms 0.739 ms 4.317 ms
3 cr0.nikhef.nl.fusixnetworks.net (37.139.138.180) 0.748 ms 2.843 ms 0.701 ms
4 br0.nikhef.nl.fusixnetworks.net (37.139.139.233) 0.686 ms 0.674 ms 0.825 ms
5 * * *
6 ae-1-3510.edge5.Newark1.Level3.net (4.69.209.70) 75.748 ms 75.661 ms 75.615 ms
7 PCCW-GLOBAL.edge5.Newark1.Level3.net (4.35.19.102) 76.054 ms 76.093 ms 76.138 ms
8 ae0.dist.edi03.steadfast.net (67.202.117.11) 76.241 ms 75.870 ms 75.930 ms
9 lookingglass.edi.steadfast.net (69.162.170.5) [open] 76.210 ms 76.335 ms 76.277 ms
Andere Provider in de US:
firewall /tmp # curl http://mirror.dal10.us.leaseweb.net/speedtest/100mb.bin -o /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 95.3M 100 95.3M 0 0 7728k 0 0:00:12 0:00:12 --:--:-- 9159k
7.7MB ~ 61Mbps netto, 77MBps line speed
Tracing the path to mirror.dal10.us.leaseweb.net (209.58.153.1) on TCP port 80 (http), 30 hops max
1 lo1.cmbr.connected.by.freedom.nl (185.93.175.226) 0.558 ms 0.574 ms 0.631 ms
2 xe-1-1-0.core2.fi001.nl.freedomnet.nl (185.93.175.237) 0.668 ms 2.430 ms 0.641 ms
3 cr0.nikhef.nl.fusixnetworks.net (37.139.138.180) 0.650 ms 0.655 ms 0.664 ms
4 br0.drtam1.nl.fusixnetworks.net (37.139.139.247) 0.737 ms 0.704 ms 0.800 ms
5 adm-b1-link.ip.twelve99.net (62.115.151.184) 1.186 ms 1.141 ms 1.280 ms
6 adm-bb3-link.ip.twelve99.net (62.115.136.194) 123.750 ms 123.489 ms 123.716 ms
7 prs-bb1-link.ip.twelve99.net (62.115.134.97) 122.343 ms 122.470 ms 122.390 ms
8 ash-bb2-link.ip.twelve99.net (62.115.112.242) 92.565 ms 92.781 ms 92.568 ms
9 atl-b24-link.ip.twelve99.net (62.115.125.128) 106.195 ms 105.987 ms 106.046 ms
10 dls-b23-link.ip.twelve99.net (62.115.123.200) 123.115 ms 123.142 ms 123.174 ms
11 dls-b1-link.ip.twelve99.net (62.115.113.85) 123.434 ms 123.992 ms 123.130 ms
12 leaseweb-svc078338-lag003924.c.telia.net (62.115.184.93) 122.786 ms 122.793 ms 122.782 ms
13 po-1.ce01.dal-13.us.leaseweb.net (173.208.123.3) 122.902 ms 122.847 ms 122.883 ms
14 mirror.dal13.us.leaseweb.net (209.58.153.1) [open] 123.258 ms 124.376 ms 123.349 ms
Zelfde Provider in NL:
firewall /tmp # curl http://mirror.nl.leaseweb.net/speedtest/1000mb.bin -o /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 953M 100 953M 0 0 106M 0 0:00:08 0:00:08 --:--:-- 105M
106MB ~ 800Mbps netto ~ 1Gbps line speed
Tracing the path to mirror.nl.leaseweb.net (5.79.108.33) on TCP port 80 (http), 30 hops max
1 lo1.cmbr.connected.by.freedom.nl (185.93.175.226) 0.566 ms 0.570 ms 0.615 ms
2 xe-1-1-0.core2.fi001.nl.freedomnet.nl (185.93.175.237) 0.698 ms 0.955 ms 0.672 ms
3 cr0.nikhef.nl.fusixnetworks.net (37.139.138.180) 0.736 ms 1.760 ms 1.043 ms
4 br0.nikhef.nl.fusixnetworks.net (37.139.139.233) 0.718 ms 0.721 ms 0.694 ms
5 speed-ix.leaseweb.com (185.1.95.147) 0.734 ms 0.720 ms 0.729 ms
6 et-19-1.agg02.ams-01.leaseweb.net (31.31.34.122) 1.030 ms 1.106 ms 1.019 ms
7 ae-102.br01.ams-01.nl.leaseweb.net (31.31.38.117) 1.276 ms 1.186 ms 1.088 ms
8 po-1.ce06.ams-01.nl.leaseweb.net (81.17.34.69) 1.098 ms 1.127 ms 1.067 ms
9 mirror.ams1.nl.leaseweb.net (5.79.108.33) [open] 1.065 ms 1.006 ms 1.103 ms
In het eerste voorbeeld is de “rate limiting” eerder de lokale harde schijf (evengoed een Sata disk, de de overhead van OS & filesystem moet je ook meetellen en die veroorzaken latency).
De rate limiting zit vermoedelijk aan de server zijde en in de afstand.
Vroeger was er een tool waarbij je lijnsnelheden op individuele routing segmenten kon “schatten” alleen het is niet meer bruikbaar doordat moderne compilers de code niet meer slikken.
Ik ben benieuwd of dit probleem ook voordoet bij mensen die een glasvezel abonnement hebben bij Freedom die via de regionale glasvezel netwerken loopt.
problemen in de code: oa. val = abs(x) waarbij x unsigned is…
veel string conversie die tegen ISO C++ ingaan, 64bit issues?.
Het is wel werkend te krijgen:
Hier zit de bottleneck… voor nyc.speedtest.clouvider.net
Met iets versnellende parameters:
./pchar -I 128 -R 10 nyc.speedtest.clouvider.net
…
8: 2001:2034:1:b7::1 (nyk-bb1-v6.ip.twelve99.net)
Partial loss: 0 / 110 (0%)
Partial char: rtt = 79.341283 ms, (b = 0.000094 ms/B), r2 = 0.187341
stddev rtt = 0.098955, stddev b = 0.000065
Partial queueing: avg = 0.003054 ms (149576 bytes)
Hop char: rtt = 3.567609 ms, bw = 90243.611678 Kbps
Hop queueing: avg = 0.000995 ms (11225 bytes)
…
12: 2a0b:f300:2:5::2 (2a0b:f300:2:5::2)
Path length: 12 hops
Path char: rtt = 79.036937 ms r2 = 0.182152
Path bottleneck: 90243.611678 Kbps
Path pipe: 891572 bytes
Path queueing: average = 0.002305 ms (149576 bytes)
Start time: Thu Aug 26 22:07:01 2021
End time: Thu Aug 26 22:18:07 2021
Het probleem met pchar kan zijn dat paden niet stabiel zijn of de volgende hop sneller antwoord dan een eerdere hop.
Dan is de bandwidth estimate --.---- dan is er vermoedelijk ook traffic shaping aan de gang.
Met de BBR Congestie algoritme verbetert het een beetje.
Upload is nog steeds te langzaam. Mijn modem traint in op 50 Mbit/s, maar tijdens het uploaden naar de server is dit rond de 10-20 Mbit/s.
Van de helpdesk na maanden terugkoppeling gehad en zij zeiden dat KPN geen ratelimiting erop kan toepassen, maar ik ben niet overtuigd.
De snelheidspatroon is exact hetzelfde als op de voormalige KPN verbinding.
Routes zijn nu wel beter. Bij KPN was dat er flink op achteruit gegaan na hun verkoop van de internationale netwerk.
Als dit probleem verholpen zou worden dan zou het heel fijn zijn.
Dit is zo’n beetje mijn enige probleem.
De routes zijn wel gewoon goed over het algemeen.
Als ik nu nog steeds bij KPN had gezeten dan had ik een hoger latency + elke week kans op packet loss die maar urenlang aan kan houden.
EDIT:
Aanvulling: Via VPN verbindingen speelt het probleem niet, maar de gevoelige data naar mijn server laat ik daar liever niet langs gaan.