Waarom je snelheid naar EU-servers lager ligt dan bij Speedtest

Speedtest meldt 290 Mbps. Je echte snelheid naar servers in de EU komt eerder rond 38 Mbps uit. Een gat van ruwweg een factor acht valt op, en bijna altijd ligt het aan de lange internationale route en niet aan je apparatuur of aan onze dienst.

Kort samengevat

Speedtest en een echte verbinding met een verre server meten verschillende dingen. Speedtest peilt de kale capaciteit van je lokale lijn over een heel korte route. Werken met servers in de EU hangt af van de vertraging en van de toestand van de internationale kanalen waar je verkeer overheen gaat. Een hoge uitslag bij Speedtest zegt dus alleen dat je lijn gezond is. De lage snelheid naar de EU botst op de fysica van lange afstanden en op de drukte in de transitnetwerken.

Hoe het gat eruitziet

Hieronder staat één en dezelfde lijn, twee keer gemeten met een paar minuten ertussen. Eerst Speedtest, tegen een server die hij zelf koos.

Twee details op dat scherm verklaren het getal grotendeels. Bij "Connections" staat "Multi", dus het cijfer is een optelsom van meerdere stromen. En de gekozen server bevindt zich in hetzelfde land. Nu dezelfde lijn, gemeten tegen de servers die het webinarverkeer echt afhandelen, op de stap "Speed" van onze eigen verbindingstester.

De download zakt met ruwweg een factor acht. De upload glijdt alleen van 26 naar 16, een veel zachter verval. Geen van beide cijfers wijst op een kapotte lijn, en waar elk van beide vandaan komt, legt de rest van dit artikel uit.

Het tweede scherm lees je beter aandachtig. "TO YOU" is wat je ontvangt, "FROM YOU" is wat je verstuurt. Presenteer je zelf? Dan telt juist het cijfer "FROM YOU", want je camera, je microfoon en je scherm verlaten allemaal je computer via de upload. Een deelnemer die alleen kijkt, hangt daarentegen aan "TO YOU". In de meting hierboven is 15,98 Mbps uitgaand ruwweg tien keer wat een presentator nodig heeft.

De opschriften op de afbeeldingen zijn Engels, want de schermen zijn in de Engelse versie vastgelegd. In een Nederlandstalige omgeving dragen dezelfde punten Nederlandse namen en staan ze op dezelfde plek.

Wat Speedtest werkelijk meet

Speedtest is erop gebouwd het hoogste getal te tonen dat hij kan halen. Zijn uitslag geeft het werk met verre servers daarom maar deels weer.

• Hij pakt de dichtstbijzijnde server. Speedtest kiest het knooppunt met de laagste vertraging, meestal in het netwerk van je eigen provider of in dezelfde stad. Het verkeer daarheen loopt kort en raakt internationale kanalen helemaal niet.
• Hij opent veel verbindingen tegelijk. Speedtest draait meerdere TCP-stromen naast elkaar, meestal 4 tot 16, en telt hun snelheid bij elkaar op. Zo omzeilt hij de grens waar één verbinding op een lange route tegenaan loopt, en die grens legt de volgende paragraaf uit. Echte programma's werken vaak met één of twee verbindingen en krijgen dat voordeel dus nooit.
• De vertraging is minimaal. Op een korte route duurt de omlooptijd, ook wel RTT, maar een paar milliseconden, dus TCP krijgt de tijd om naar de volle snelheid van de lijn op te lopen.

Speedtest toont dus de labwaarde van je lijn. Wat je krijgt bij het uitwisselen van gegevens met een server in een ander land, laat hij niet zien.

Bandbreedtevertragingsproduct en het TCP-venster

Het grootste deel van het gat komt door dit ene mechanisme.

TCP verstuurt gegevens in vensters. De verzender duwt een portie naar buiten en wacht op de bevestiging dat die aankwam, en pas daarna gaat hij verder. De hoogste snelheid van één TCP-verbinding volgt een eenvoudige formule.

Snelheid = Venstergrootte / Vertraging (RTT)

Om de lijn helemaal vol te krijgen, moet het venster minstens zo groot zijn als het bandbreedtevertragingsproduct, kortweg BDP.

BDP = Bandbreedte × RTT

Vul de cijfers in voor die lijn van 290 Mbps, bij een vertraging naar een EU-server van ongeveer 50 ms.

BDP = 290.000.000 bit/s × 0,05 s = 14.500.000 bits = 1,81 MB

Er moet dus op elk moment ruwweg 1,8 MB onderweg zijn, anders raakt de lijn niet vol. Zit één kant vast aan een beperkte venstergrootte, dus aan de klassieke 64 KB zonder vensterschaling? Dan komt het plafond voor één verbinding hierop uit.

Snelheid = 65.536 bytes × 8 bit / 0,05 s ≈ 10,5 Mbps

Daarom blijft één verbinding naar een verre server op 10 tot 20 Mbps steken, terwijl de lijn zelf voor honderden megabits bedoeld is. Op een korte route met een RTT van 2 ms leverde datzelfde venster ruim 260 Mbps op, en daarom duikt het probleem bij Speedtest nooit op. Hoe hoger de vertraging, hoe sterker het effect. Er is hier niets kapot, want zo gedraagt het protocol zich nu eenmaal.

Vertraging en de fysica van lange verbindingen

De vertraging op een lange route bestaat uit meerdere delen, en sommige daarvan krijg je er helemaal niet uit.

Licht loopt door glasvezel met ruwweg 200.000 km/s, merkbaar trager dan in vacuüm, want glas breekt het licht. Elke duizend kilometer route kost ongeveer 5 ms in één richting, dus zo'n 10 ms voor de omloop. Rechte routes bestaan bovendien nauwelijks, dus de echte weg is meestal langer dan de afstand op de kaart.

Daarbij komt de vertraging op elk tussenliggend knooppunt. Een router verwerkt het pakket, zet het in een wachtrij en stuurt het door. Op weg naar een EU-server liggen er meestal 10 tot 20 van zulke knooppunten, ook wel hops genoemd, en elk legt er zijn deel bovenop. Hoe hoger de RTT uiteindelijk uitvalt, hoe lager het plafond voor één verbinding volgens de formule hierboven.

Pakketverlies en het effect op TCP

Zelfs klein pakketverlies op een internationaal kanaal snijdt de uiteindelijke snelheid flink terug. TCP leest een verloren pakket als teken van overbelasting, remt daarom af en bouwt het tempo daarna weer op. Dat verband vangt de formule van Mathis.

Snelheid ≈ MSS / (RTT × √p)

MSS is de maximale segmentgrootte, meestal rond 1460 bytes, RTT is de vertraging en p is het aandeel verloren pakketten. De snelheid daalt omgekeerd met de wortel uit het verliespercentage en hangt rechtstreeks af van de vertraging.

In de praktijk zien de cijfers er dramatisch uit. Bij een RTT van 50 ms en een gewone MSS houdt al 0,1 procent verlies één verbinding op ongeveer 7 Mbps. Eén procent verlies drukt die naar ruwweg 2,3 Mbps, twee procent naar onder 1,7 Mbps. Op lange transitroutes is 1 tot 2 procent verlies in de spits volstrekt normaal. Waar het die waarden haalt, bijt het harder dan de vensterlimiet hierboven, en daarom wordt een route die 's ochtends alleen traag lijkt 's avonds onbruikbaar.

Routering en peering

De weg die je verkeer naar een EU-server aflegt, is niet recht. Hij loopt door een keten van operators en over het routeringsprotocol BGP, en dat kiest zijn pad op commerciële en technische gronden en niet op de kortste afstand.

Daaruit volgen een paar typische problemen. Een route kan door een derde land lopen terwijl er een kortere bestaat, en dan stijgen de vertraging en het verliesrisico tegelijk. Het verkeer passeert bovendien de koppelpunten tussen netwerken, dus peeringpunten en transitkanalen. Een verstopt koppelpunt is precies de plek waar de snelheid inzakt. Ook asymmetrische routering komt vaak voor, waarbij pakketten via de ene weg heen en via de andere terug gaan. Dat maakt elke diagnose troebel. Internationale capaciteit koopt een provider bovendien in, en wie zuinig inkocht, komt in de spits tekort.

Overbelaste internationale kanalen van je provider

Lokaal verkeer, binnen de stad en binnen het land, heeft bij de meeste providers ruimte over. Daarom laat Speedtest naar een server dichtbij ook altijd een hoog getal zien. Internationale kanalen zijn duurder en providers kopen er maar beperkt van in, en in de avondspits worden juist die kanalen het knelpunt. Dat verklaart waarom de snelheid naar de EU over de dag merkbaar schommelt, terwijl de lokale Speedtest gelijkmatig hoog blijft.

Andere technische factoren

Naast de hoofdoorzaken werken nog een paar dingen door op de snelheid naar een verre server.

MTU en fragmentatie. Is de MTU op de route kleiner dan verwacht, dan vallen pakketten uiteen en zakt de efficiëntie. Een scheef ingestelde PMTUD, dus het bepalen van de MTU op het pad, leidt tot zwarte gaten en vastgelopen overdrachten.

Bufferbloat. Opgeblazen buffers op tussenknooppunten tillen de vertraging onder belasting omhoog en brengen de stroomregeling van TCP in de war. De echte snelheid zakt daardoor verder.

Shaping en prioritering, ook wel QoS. Sommige providers knijpen internationaal verkeer bewust af of zetten het achteraan, soms ook maar één bepaald soort verkeer. Je ziet dat meteen terug in je snelheid.

Protocoloverhead. De kopgegevens van TCP, IP en versleuteling eten een deel van de bandbreedte op. Op een korte route zie je daar niets van. Samen met verlies en vertraging op een lange route tikt het wel aan.

Je eigen omgeving. Wifi in plaats van kabel, een overbelaste thuisrouter, een virusscanner of een VPN op het apparaat drukken de echte snelheid net zo goed. Sluit dat eerst uit voordat je verder weg gaat zoeken.

Waarom het niet aan je apparatuur of aan onze dienst ligt

Een hoge uitslag bij Speedtest bewijst dat je apparatuur en je lokale lijn gezond zijn en de beloofde snelheid leveren. De terugval bij EU-servers komt ergens anders vandaan. Schuldig zijn de vertraging op de lange route, de vensterlimiet van één TCP-verbinding, pakketverlies en de toestand van de internationale kanalen van je provider. Dat alles ligt buiten onze dienst en buiten je apparatuur, want het hoort bij het stuk netwerk tussen je provider en de backbone-operators.

En nog iets, voordat je achter de cijfers aan gaat. Een webinar vraagt veel minder dan een bestandsoverdracht, dus 20 Mbps naar de EU is voor ons helemaal geen probleem. Een presentator heeft ongeveer 1,6 Mbit/s uitgaand nodig, met schermdeling 3,2, en een deelnemer genoeg voor elke spreker in de uitzending. Alle cijfers noemt technische vereisten. Stabiliteit telt hier zwaarder dan kale snelheid. Lopen je evenementen soepel, dan is het gat met Speedtest een curiositeit en geen defect.

Hoe je het zelf nameet

Een paar controles wijzen de oorzaak aan.

• Start Speedtest met de hand en kies een server in Duitsland of in Finland. Al onze servers staan in de EU, verdeeld over Duitsland, Frankrijk, Nederland en Finland, maar het webinarverkeer zelf dragen de Duitse en de Finse machines. De Nederlandse en de Franse versturen de uitnodigingen voor komende evenementen, dus een meting tegen die twee vertelt je over een route die je webinars nooit nemen. Duitsland of Finland toont wel de echte snelheid over de route die je in de praktijk gebruikt, en niet die naar de dichtstbijzijnde lokale server.
• Volg de route. Het commando tracert onder Windows, of traceroute onder macOS en Linux, levert richting onze server de keten van knooppunten op, met de vertraging bij elk knooppunt. Verlies en vertraging laat het hulpmiddel mtr duidelijker zien, onder Windows heet dat WinMTR, en je laat het in de spits een paar minuten draaien.
• Vergelijk één verbinding met meerdere. Is een download over meerdere stromen snel en over één stroom traag? Dan bevestigt dat de vensterlimiet van TCP op de lange route.
• Heb je de technische middelen? Meet de doorvoer naar het verre knooppunt dan rechtstreeks met iperf3, eerst met één stroom en daarna met meerdere.

In onze verbindingstester staat bovendien een link naar een aparte test van de internetkwaliteit, met snelheid, ping en jitter. Zo leg je snel vast hoe je lijn er op een bepaald moment voor staat.

Wat je kunt doen

Tonen je controles hoge vertraging of pakketverlies op het internationale traject? Stap dan met concrete gegevens naar je provider, dus met de route-trace en een meting van mtr met het tijdstip erbij. De route aanpassen of de internationale aansluiting uitbreiden is werk voor de provider. Van onze kant geven we de adressen van onze servers voor gerichte diagnose en helpen we je de resultaten lezen. Schrijf ons in de online chat, dan sturen we ze op.

Onder de streep

Een uitslag rond 290 Mbps bij Speedtest bevestigt dat je lijn gezond is. De terugval naar onder 40 Mbps bij EU-servers hoort erbij. Hij komt van de vertraging op de lange route, de vensterlimiet van één TCP-verbinding, pakketverlies en de drukte op de internationale kanalen van je provider. Die oorzaken zitten in het netwerk tussen jou en ons, niet in je apparatuur en niet in onze dienst. Een eenvoudige diagnose van de route laat zien welke van de vier de schade aanricht.

Veelgestelde vragen

Moet ik een snellere lijn kopen om dit op te lossen?

Nee, want een webinar vraagt veel minder dan een bestandsoverdracht en 20 Mbps naar de EU is voor ons helemaal geen probleem. Een presentator heeft ongeveer 1,6 Mbit/s uitgaand nodig, met schermdeling 3,2, en alle cijfers noemt technische vereisten. Stabiliteit telt hier zwaarder dan kale snelheid. Lopen je evenementen soepel, dan is het gat met Speedtest een curiositeit en geen defect.

Mijn download zakte acht keer, mijn upload nauwelijks. Welke telt?

De upload, als je zelf presenteert. Je camera, je microfoon en je scherm verlaten allemaal je computer via de upload, en dat is het cijfer "FROM YOU". Een deelnemer die alleen kijkt hangt aan "TO YOU", dus dezelfde meting leest anders afhankelijk van je rol bij het evenement. In de meting hierboven gleed de upload maar van 26 naar 16 Mbps, ruwweg tien keer wat een presentator nodig heeft.

Tegen welke Speedtest-server meet ik voor een eerlijke vergelijking?

Tegen een in Duitsland of in Finland. Al onze servers staan in de EU, verdeeld over Duitsland, Frankrijk, Nederland en Finland, maar het webinarverkeer zelf dragen de Duitse en de Finse machines. De Nederlandse en de Franse versturen de uitnodigingen voor komende evenementen. Een meting tegen die twee vertelt je dus over een route die je webinars nooit nemen.

Wat hiervan kan ik zelf oplossen?

Begin bij jezelf, want wifi in plaats van kabel, een overbelaste thuisrouter, een virusscanner of een VPN op het apparaat drukken de echte snelheid. Is het daar schoon en tonen je controles nog steeds hoge vertraging of pakketverlies op het internationale traject? Dan ligt de oplossing bij je provider. Stap daar met concrete gegevens heen, dus met de route-trace en een meting van mtr met het tijdstip erbij. De adressen van onze servers voor gerichte diagnose geven we je graag, dus schrijf ons in de online chat.

Waarom is de route 's ochtends prima en 's avonds onbruikbaar?

Internationale kanalen kopen providers maar beperkt in, en in de avondspits worden ze het knelpunt. Lokaal verkeer heeft ruimte over, en daarom blijft Speedtest naar een server dichtbij de hele dag hoog. Pakketverlies volgt dezelfde curve, en 1 tot 2 procent op lange transitroutes is in de spits volstrekt normaal. Bij een RTT van 50 ms houdt één procent verlies één verbinding op ruwweg 2,3 Mbps. Precies dat maakt van een alleen maar trage route een onbruikbare.