Elke tool is gespecialiseerd in iets
Stel, je moet een snelheidstest doen op circuit. Kies je een gezinswagen, een monovolume, een SUV of een sportieve berline? Je kan met al die wagens een snelheidstest doen, maar het resultaat zal altijd anders zijn. Dat lijkt ons evident!
Welnu, hetzelfde kan bij internetsnelheidstesten. En dat is een pak minder evident. Daarom geven we je de raad om voorzichtig te zijn en je resultaten te staven door meerdere tools te gebruiken.
Bijvoorbeeld:
- De tool Speedtest.net (van Ookla) wordt wereldwijd gebruikt om internetsnelheden te meten.
- De oplossing die Test-Aankoop gebruikt, is NDT (M-Lab), dat oorspronkelijk ontwikkeld werd door universiteiten om netwerkstoringen te verhelpen. (Meer info)
- FAST.com is een erg eenvoudige tool ontwikkeld door Netflix. (Meer info)
- De oplossing nPerf.com is erg compleet en is standaard de keuze van veel internetgebruikers. (Meer info)
Veel elementen kunnen de resultaten beïnvloeden
Je browser, je computer, het wifigebruik, de aanwezigheid van andere gebruikers, het netwerk... maar ook de tool die je gebruikt.
Elementen in het design van dergelijke tools kunnen het resultaat sterk beïnvloeden.
- Het vermogen van de tool om simultane testenuit te voeren.
De testen nPerf, Ookla/Speedtest, FAST.com voeren simultaan een aantal testen uit.
Dat is de beste manier om zoveel mogelijk uit je browser, je processor en de beschikbare bandbreedte te halen. Tegenwoordig werken de meeste applicaties trouwens zo.
NDT voert maar één test uit, één sessie. Het resultaat kan dus enorm verschillen van poging tot poging.
- Het algoritme dat de resultaten van de simultane testen aggregeert.
Om het gemiddelde te berekenen, laat nPerf de 5 (%) snelste en de 5 (%) traagste verbindingen achterwege. Bij Ookla is het resultaat het beste gemiddelde in een reeks achtereenvolgende testen. (Die reeks is 50 % van de metingen).
Uitleg met meer diepgang
Het MIT (Massachusetts Institute of Technology) publiceerde in 2010 een interessant onderzoek waarin de verschillende snelheidstesten vergeleken werden (ook Ookla/Speedtest en NDT van M-Lab).
In het fragment over Ookla, vind je:
- Uitleg waarom het zo belangrijk is om een snelheidstest over verschillende sessies uit te voeren. Dat is zeker handig als de te meten snelheden hoog zijn.
(...) By employing multiple TCP connections they don’t harm the performance of tests running from machines that would be capable of saturating a single TCP connection, and they gain the benefit of moving the likely performance bottleneck back into the network (assuming that is what the measurements are trying to understand).
Multiple simultaneous TCP connections are representative of many typical applications on the Internet today. Web browsers like Firefox, Microsoft’s Internet Explorer 8, and Google’s Chrome open four to six simultaneous connections per domain. Coupled with the common practice of websites using two or more sub-domains, the number of simultaneous TCP connections can easily be four to eight.48 Other applications like peer-to-peer traffic similarly open multiple simultaneous TCP connections. (There are exceptions to this -- web-based video traffic tends to be carried on a single TCP connection and large file transfers also employ a single TCP connection.) So employing multiple TCP connections both increases the odds that the test will measure a bottleneck in the network and is a representative test for many common usage patterns. (Pagina 28)
- Uitleg over het algoritme dat Ookla gebruikt om de resultaten van de verschillende simultaan uitgevoerde testen samen te vatten. Ookla krijgt heel wat kritiek te slikken, omdat het een deel van de resultaten negeert. (Hieronder de methode die Ookla in 2010 gebruikte voor http-testen. In 2010 werd die methode aangepast.)
(...) The next important differentiator for the Speedtest/Ookla methodology relates to how they filter the test results. Ookla's results are based on disregarding the fastest 10% and slowest 30% of the measurements collected while the TCP connections were in progress. This is important because they deliberately do not take the total data transferred divided by the total time ...(Pagina18)
In het fragment over NDT, vind je:
- Uitleg over waarom NDT zo belangrijk is om netwerkstoringen te identificeren en op te lossen en over het feit dat de tool maar één TCP-verbinding gebruikt.
(...) Understanding these local bottlenecks is indeed one of the prime reasons the test was built in the first place.
Several studies have shown that the majority of network performance problems occur in or near the users’ desktop/laptop computer. These problems include, but are not limited to, duplex mismatch conditions on Ethernet […] links, incorrectly set TCP buffers in the user’s computer, or problems with the local network infrastructure. The NDT is designed to quickly and easily identify a specific set of conditions that are known to impact network performance... (Pagina 30)