Ik gebruik pfsense 2.4.5, in principe als VM (ESX7) maar heb het ook met barebone pfsense getest.
Wanneer ik een speedtest doe dan kom ik netjes op 900/900 uit (ongeveer) wel beetje afhankelijk van welke server ik kies. Maar zoals de meeste hier wel weten zegt dat niet alles. Als ik bijvoorbeeld een file upload kom ik niet boven de 30 MB/s uit. En als ik iperf testje doe richting mijn IP kom ik niet boven de 200 Mbit uit. Richting een andere iperf server (op een KPN 200/200) kom ik niet boven de 100Mbit uit.
Tja, je meet steeds verschillende dingen op verschillende manieren. 30MB/s is ca. 300Mbit/s. Dat vind ik heel acceptabel. iperf: Meet je UDP of TCP? Pakket grootte? Hoe lang? Wat zijn de instellingen van de iperf server? Zit daar een limiet op?
Ik heb een keer een file gedownload van HP met wget. 20Mbit/s. Toen met âaxelâ in 5 streams, bijna het vijf voudige.
De vraag is niet meer zozeer: hoe snel is je verbinding, maar wat meet je nou eigenlijk?
Dank voor je antwoord, ik begrijp wat je zegt, ik dacht eigenlijk door verschillende dingen te meten een beter beeld te krijgen
Maar het zou toch wel zo moeten zijn op een Tweak (1Gbit) verbinding dat als de server aan de verzend kant het trekt, ik met ongeveer 100MB/s zou moeten kunnen downloaden?
Ik zie dat namelijk regelmatig gebeuren bij bekenden van mij, die downloaden dan vanaf een steam achtige game server (ik game niet, dus weet niet precies wat het is) en dat gaat soms nog wel (iets) harder dan 100MB/s. Net als dat uploaden vanaf mijn Tweak verbinding toch ook wel harder moet kunnen dan 15MB/s. Als ik intern vanaf diezelfde Nextcloud server download haal ik de 100MB/s wel. Server draait op SSDs (wat ik hiermee wil zeggen, is dat de lokale storage geen beperking zou moeten opleveren).
Hoe zou jij dit controleren/meten m.b.v. iperf? Welke iperf command zou je gebruiken? ( ik gebruikte overigens TCP, geen multi connections, en 30 sec, en de iperf server heeft geen limiet voor zover ik weet).
TCP betekent dat je moet kijken naar het bandwidth/delay product, en kun je de maximale bandbreedte nooit halen door de zaagtand die extreem wordt bij grote bandbreedtes.
Als een game claimt dat ie op 1Gbit/s meer dan 100MB/s haalt dan kan het ding niet tellen, want dat kan niet. Je hebt ongeveer 10 bits nodig gemiddeld om 8 bits te transporteren door overhead.
en dat levert me hier via WiFi constant 35 - 40MB/s op. En dan ben ik tevreden. Maar je kunt nog meer load toevoegen, door nog een ookla en upload&download te gaan doen kijken of die elkaar beinvloeden. Als niet, dan heb je nog meer bandbreedte over.
100MB/s is 800Mbps. Dat is makkelijk haalbaar op een 1Gbps verbinding, mits je bandwidth/delay product het toelaat en je verbinding schoon genoeg is zodat je TCP zân maximum kan bereiken.
De overhead van TCP over Ethernet is ongeveer 3 procent, geen 20.
100MB/s is 1Gbit/s. Je vergeet start en stop bits. 10 bits per byte. En de zaagtand van TCP op een 1Gbit/s verbinding vanaf een Windows machine is significant. Op Linux kun je BBR congestion control gaan gebruiken om je performance nog op te schroeven (zie https://en.wikipedia.org/wiki/TCP_congestion_control).
âStart en stop bitsâ? Het is geen seriĂ«le verbinding. En zelfs als je 1.048.476 voor âmegaâ gebruikt, wat je normaal bij data rates niet doet, is het 839 mijoen bps. Dat het lastig is om met 1 TCP stream op een high-delay gigabit path 800+ Mbps te halen is zeker waar. Maar met een aantal streams in parallel is het geen rocket science, ook onder Windows niet. Mits geen packet loss en een stabiele round trip time.
Ik begrijp wat jullie zeggen, maar hoe test ik dan op een juiste manier (eventueel dus met meerdere TCP streams) of die verbinding een beetje in de van de 1Gb komt? Al is het alleen maar voor mijn gemoedsrust
