Lage snelheid naar servers in de VS

Hallo,

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.

Het betreft hetzelfde probleem als wat ik bij KPN had:
https://forum.kpn.com/internet-9/langzame-downloadsnelheid-bekabeld-naar-servers-in-de-vs-en-omgeving-515612

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 krijg deze snelheidsverloop te zien als ik kijk bij Windows taakbeheer:

Dit is voor elke download bijna precies hetzelfde.

Als ik met een Nederlandse VPN verbind naar bovengenoemde servers haal ik wél de volle snelheid (rond de 160-200 Mbps).

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.

Begrijp ik het goed dat je via een VPN de snelheid meet? En als je een Nederlandse VPN server gebruik wel de verwachte snelheden haal?

Dan lijkt het mij eerder een probleem van de VPN.

Ik heb het gemeten zonder VPN, en dan ervaar ik het snelheidsprobleem.

Maar als ik een Nederlandse VPN server gebruik dan haal ik wel gewoon de volle snelheid.

1 like

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 weet niet wat voor VPN gebruikt, maar die hebben wellicht een netwerk met dedicated lines (nou ja, een gereserveerd stukje) waardoor hun verbindingen naar diverse streken in de wereld beter zijn dan wanneer je via het “gedeelde” pad moet. Zeker als je het probleem al bij KPN had, klinkt dit logisch, dat verkeer kost simpelweg ook gewoon geld. Verder zou je timing misschien iets te maken kunnen hebben met corona, en dat een hoop meer mensen met hun thuiswerken bijvoorbeeld US-based resources nodig hebben.

@MartijnZ

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.

@mcfab

Ik heb het getest met ProtonVPN (PLUS servers).

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.

Als je een linkje hebt wil ik het wel testen

@Noci

Bij mij loopt de aansluiting via KPN en dan naar Cambrium. De FRITZ!Box geeft in de logs aan
broadband PoP: asd-itxams9-rtr2.cambrium.net

@MartijnZ

*http://mirror.wdc1.us.leaseweb.net/speedtest/100mb.bin
*http://mirror.dal10.us.leaseweb.net/speedtest/100mb.bin
*https://lg.chi.psychz.net/200MB.test
*https://lg.va.psychz.net/200MB.test
*https://lg.texas.psychz.net/200MB.test
*http://testfile.chi.steadfast.net/
*http://testfile.edi.steadfast.net/

Deze zijn wat groter dus kan je overslaan als het nodig is:

*http://nyc.speedtest.clouvider.net/1g.bin
*http://atl.speedtest.clouvider.net/1g.bin
*http://la.speedtest.clouvider.net/1g.bin

Ik heb deze genomen, omdat de aanlooptijd te lang is voor de 100mb testjes. Ik loop van 2.5MB/s op naar 11.1MB/s (88Mbps), dus dat ligt ook (ver) onder mijn lijnsnelheid.

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

Hmm, dus er is inderdaad ergens aan de kant van Freedom rate-limiting, waarschijnlijk bij hun upstream?

nee hoor, vanaf een XS4ALL verbinding (glas) zie ik exact hetzelfde patroon

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.

heb je een naam/repository?

Hmm, oké…

Ik ben benieuwd of dit probleem ook voordoet bij mensen die een glasvezel abonnement hebben bij Freedom die via de regionale glasvezel netwerken loopt.

Artikel over de achtergrond: https://www.cc.gatech.edu/~dovrolis/Papers/bwest_survey.pdf

pathchar
https://ee.lbl.gov/ (binary only, 32-bit)
pathchar - Everything2.com (explanation)

er blijkt een rewrite te zijn: pchar
http://www.kitchenlab.org/www/bmah/Software/pchar/
(Note: 2005 wil de code wel weer terug hebben).

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.