Netwerksnelheid meten 1


In november schreef ik over het gebruik van goede netwerkkabel en waar je dat aan kunt herkennen. Echter er is nog een veel simpeler methode om de kwaliteit van je netwerk te beoordelen en dat is simpelweg meten hoe snel je er data overheen kunt sturen.

Hoe te meten?

Dat meten van netwerksnelheid kan op diverse manieren, zoals een groot bestand kopiëren van de ene computer naar een andere. Echter dan zit je met veel meer onbekende parameters zoals:

  • Snelheid harde schijf
  • Overijverige virusscanner
  • Andere lees- en schrijf-acties op een harde schijf van een van beide computers
  • Optimalisaties van het besturingssysteem om een netwerk niet te veel te belasten bij kopieeracties
  • Protocol overhead bij het kopieren
  • Beperking CPU
  • Invloed van de firewall

Om de impact van al deze parameters zo veel mogelijk te beperken, is een tool nodig die puur en alleen zelf gegenereerde data over en weer stuurt zonder de rest van de onderdelen van de PC te benaderen.

Benchmark tools

Er is een aantal van dergelijke netwerk-tools beschikbaar. Ikzelf gebruik altijd iperf, omdat dit standaard in diverse Linux-distributies aanwezig is en er ook een MaxOS- en Windows-versie van is.  Een vergelijkbare test-tool is NetIO, wat ook werkt onder een groot aantal besturingssystemen. Beide bieden ongeveer dezelfde mogelijkheden, maar zijn helaas niet compatibel met elkaar. Dus je kunt niet iperf aan de ene kant als server laten werken en aan de andere kant NetIO als client.

Het idee is heel simpel, je start op de ene computer iperf of NetIO als server en op een andere computer maak je verbinding als client. Ik ben zelf voorstander van commandline tools, omdat dat net even wat flexibeler is wanneer de “andere kant” niet echt binnen handbereik staat. Maar voor de liefhebbers van een GUI, zijn die ook verkrijgbaar voor beiden. (zie de links aan het eind)

Voor zowel NetIO als iperf stel je de server-kant in dmv. de commandline optie “-s”.

D:\DataGijs\Downloads\Iperf\Iperf\Release>iperf -s

De client-kant moet weten naar welke computer verbonden moet worden, dus die geef je dan op:

D:\DataGijs\Downloads\Iperf\Iperf\Release>iperf -c htpc -r
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to htpc, TCP port 5001
TCP window size: 512 KByte (default)
------------------------------------------------------------
[296] local 192.168.1.141 port 49544 connected with 192.168.1.3 port 5001
Waiting for server threads to complete. Interrupt again to force quit.
[ ID] Interval Transfer Bandwidth
[296] 0.0-10.0 sec 1.10 GBytes 949 Mbits/sec

Bovenstaand voorbeeld is tussen mijn HTPC, Intel core i3 die op Linux draait en mijn desktop PC, een Intel core i7 die Windows 8 draait. Het netwerk tussenbeide is Gigabit.

De belangrijkste opties voor NetIO zijn:

  • -s draai als server
  • -b <size>[k] Gebruik deze blok-grootte  (Standaard wordt 1,2,4,8,16 en 32k gebruikt)
  • <ip-adres> adres van de server.

De belangrijkste opties voor iperf zijn:

  • -s draai als server
  • -d voer up- en download tegelijk uit. (werkte bij mij niet altijd even goed)
  • -r zelfde als -d, maar dan na elkaar.
  • -c <ip-adres> De -c optie moet meegegeven worden om als client te kunnen draaien.

 

 

Voorbeelden van GUIs

Van zowel NetIO als iperf heb ik een paar GUI’s getest.

Allereerst NetIO. Links de GUI en rechts een SSH-shell (Putty) met daarin de uitvoer van de server-kant.

 

En ook iperf, met Jperf als GUI:

De Jperf-GUI gaf in eerste instantie heel lage waarden, van zo’n 300 Mbps, maar dat werd een stuk beter na het vergroten van de gebruikte buffers (linksonder van de GUI).

Problemen bij het testen

Bij het testen kwam ik een aantal problemen tegen:

  • De firewall die verkeer blijft blokkeren tot je toestemming hebt gegeven.
  • Processorkracht van de laptop liet soms te wensen over en crashes (blue screen) bij bepaalde netwerk-tests. Een driver-update van Intel voor de WiFi bleek de oplossing voor beide.
  • Tegelijkertijd up- en download verkeer genereren werkt niet goed met alle versies. De latere versies van iperf (2.0.5) kunnen zelfs crashen wanneer je ook ‘de andere kant op’ wilt testen (-d of -r optie). Dan moet je de rol van server en client omdraaien.
  • Naamgeving van sommige machines hier werkte op de clients niet altijd even goed, omdat deze naar IPv6 adressen verwezen, dus intypen van IP-adressen ipv. een naam zoals “laptop”, is dan de oplossing. Er zijn ook vlaggetjes om via IPv6 te testen. 
  • Iperf lijkt nogal kritisch te zijn voor wat betreft de volgorde van de parameters.
  • Sommige kabels bleken ook echt niet zo goed te zijn. Bijvoorbeeld verkeer de ene kant op haalt dan 600 a 700 Mbps, terwijl de andere kant op echt niet boven de 300 Mbps uitkomt. Test geslaagd dus 🙂

Verschil tussen draad en draadloos

Als je toch aan het testen bent, is het ook handig om eens te kijken wat verschillende mediums voor bandbreedte halen. Puur gelet op de specs, zou je verwachten dat een modern WiFi netwerk (300 Mbps 802.11N)  ongeveer 30% van de snelheid van Gbit zou kunnen halen. Helaas is dat in de praktijk toch net even wat anders.

Ik heb op de 2e verdieping hier een TP-Link TL-WR1043ND router staan met DD-WRT erop. Dit is een 2.4GHz “N” WiFi router die alleen maar als accesspoint dienst doet. Dus geen router dingen doet. Door de 2 verdiepingen blijft er beneden maar zo’n 48 Mbps van over. Als modem/router heb ik beneden een FritzBox 7340 staan, die ofwel op 2.4GHz kan werken, of op 5 GHz. De afstand tot mijn laptop is in deze tests ongeveer 7 meter geweest, zonder muren ertussen.

Ik ben in de gelukkige positie dat hier in de buurt heel weinig WiFi-netwerken actief zijn, dus ik kan redelijk goed testen wat haalbaar is. In stedelijk gebied met een aantal (studenten-) flatgebouwen in de buurt zal de behaalde snelheid aanzienlijk lager kunnen uitvallen.

Praktijksnelheid draadloos netwerk 5GHz en 2.4GHz vergeleken

 

Zoals te zien, is er van de 48 Mbps die in de taskmanager te zien is, in de praktijk ongeveer 2 MByte/s over. Theoretisch zou dat 6 kunnen zijn, oftewel ongeveer 30% blijft er over.

De 130 Mbps van de blauwe staafjes presteert nog wel redelijk, met snelheden tot 8 MByte/s, oftewel zo’n 64 Mbps. Dat is ongeveer 50% van de “beloofde” snelheid.

De 5 GHz verbinding haalt zo’n 80 a 90 Mbps in de praktijk en ook met bestanden kopiëren heb ik dat ook regelmatig kunnen halen. Echter als je dat afzet tegen de vermelde snelheid van je verbinding, is dat nog steeds maar zo’n 40%.

Zet je dit uit tegenover de praktijk-snelheid van wat je over een bedraad Gbit netwerk kunt halen (950  Mbps is ongeveer het maximum in de praktijk), dan valt de WiFi-snelheid toch behoorlijk in het niet:

Gbit netwerksnelheid (blauw) tegenover verschillende WiFi ‘N’ netwerken. WiFi is zeker een factor 10 langzamer

Ik heb deze grafiekjes in Excel gemaakt van de data die de NetIO GUI verzameld had. Nadeel van de export van de NetIO GUI is dat het in regels gerangschikt is en niet in kolommen. Dat maakt het rechtstreeks verwerken een stukje lastiger.

Je kunt echter ook heel simpel grafiekjes maken door een screenshot te nemen van de taskmanager van Windows zelf:

Up- en download over het netwerk, getoond door de Windows 8 taskmanager. Het verkeer is gegenereerd door iperf met de -r optie.

Conclusie

  • Met goede kabel (en voldoende CPU-kracht aan beide kanten) is zo’n 95 – 98% van de netwerksnelheid te halen
  • WiFi levert zo’n 30% tot maximaal 50% van de linksnelheid als bandbreedte op.
  • Blocksize heeft redelijk invloed op de maximale snelheid, al heb je daar als gebruiker lang niet altijd veel invloed op.

Links

 

 


Leave a comment

Your email address will not be published. Required fields are marked *

One thought on “Netwerksnelheid meten