[TCP] Te hoge snelheid

[Verwijderd]

Vandaag ben ik van mening dat ik alles gezien heb .

Volgens een zelf geschreven applicatie (zie: \[C++] Vage socket situatie...) trek ik maarliefst 140Mbit over een 100Mbit verbinding. Volgens mij is dit onmogelijk dus hebben we dezelfde verbinding getest met IPerf. Deze trekt in dual test mode (2 verbindingen) ook 140Mbit per seconde over de lijn.

Binnen de testopstelling wordt er gebruik gemaakt van een tweetal laptops met elk een 100Mbit netwerkkaart. Daartussen zit een 10/100Mbit switch. En het hele verhaal is met UTP Cat-5 straight kabels geschakeld. De UTP kabels zijn 2 en 3 meter lang.

Een dual test houdt in dat er van af de eerste laptop een verbinding wordt geopend naar de tweede laptop. Tegelijkertijd wordt er vanaf de tweede laptop een verbinding geopend naar de eerste laptop. Feitelijk gaat het verkeer dus tegelijkertijd 2 kanten uit. Dit is IPref.

Onze eigen applicatie stuurt een blok van 4KBytes naar de andere laptop. De andere laptop reageert hier direct op met een blok van 4KBytes. En dit ping pong effect gaat continu door.

Zowel de IPerf applicatie en onze eigen applicatie zorgen op deze manier voor een throughput van maarliefst 120-140Mbit per seconde. Heeft iemand een idee wat er hier fout gaat? Ik heb niets tegen hoge snelheden maar ze moeten wel realistisch zijn .

DUMeter is het overigens helemaal eens met de te hoge snelheiden .

VERZOEK/IDEE:
Wellicht een idee als iemand dezelfde test als ons wil uitvoeren over een 100Mbit netwerk.
IPerf is te downloaden op: http://dast.nlanr.net/Projects/Iperf/.

De commandline voor de iperf client is: iperf -c [ip van de server] -t 30 -i 1 -d -L 5002 -w 16K -l 16K
De commandline voor de iperf server is: iperf -s -l 16K -w 16K

B.v.d.

PS: Het hele verhaal is ook reeds uitgetest andere PC's en dit maakt in zijn totaliteit geen verschil.

[ Voor 16% gewijzigd door Verwijderd op 20-09-2006 10:24 . Reden: Even wat extraatjes toegevoegd ]

[Wirf]

Full duplex

100mbit heen, 100 mbit terug = 200 mbit

dus eigenlijk heb je nog niet eens het maximale bereikt

[Verwijderd]

Okee, dat was onze eerste gedachte. Echter, waar blijft de resterende 60-80Mbit??? Is dit allemaal overhead? Dit was ook met name de reden dat we full duplex niet als oplossing hebben beschouwd. Is er een mogelijkheid om uit te zoeken hoeveel % er van de lijn daadwerkelijk gebruikt wordt? Om dus feitelijk te zien hoeveel % van de lijn uit data bestaat en hoeveel % er uit overhead bestaat (TCP protocol en dergelijke). Is hier een tool voor te vinden?

[TrailBlazer]

als je je window wat groter maakt zal je wel meer throughput halen. Throughput bij TCP is
window/RTD
Als je dit uitrekent met 1 ms delay kom je op 128 Megabit/seconde per TCP stream uit.

Full duplex is inderdaad het antwoord. Zet je kaartjes maar eens op halfduplex

[ Voor 30% gewijzigd door TrailBlazer op 20-09-2006 10:53 ]

[Gerco]

Verwijderd schreef op woensdag 20 september 2006 @ 10:50:
Okee, dat was onze eerste gedachte. Echter, waar blijft de resterende 60-80Mbit???

Die gebruik je niet Als de ene laptop data aan het sturen is, is de andere aan het ontvangen en andersom. Je gebruikt dus niet tegelijkertijd de zend en ontvang "lijn" van je full-duplex verbinding.

Dat je op deze manier toch >100Mbit haalt verbaast me wel eigenlijk, want je hebt in feite van je full-duplex verbinding half-duplex gemaakt door hem slecht te gebruiken

[TrailBlazer]

Gerco schreef op woensdag 20 september 2006 @ 10:55:
[...]

Die gebruik je niet Als de ene laptop data aan het sturen is, is de andere aan het ontvangen en andersom. Je gebruikt dus niet tegelijkertijd de zend en ontvang "lijn" van je full-duplex verbinding.

Dat je op deze manier toch >100Mbit haalt verbaast me wel eigenlijk, want je hebt in feite van je full-duplex verbinding half-duplex gemaakt door hem slecht te gebruiken

wie zegt dat de server niet vast het volgende pakket stuurt voordat de pong van de voorgaande is ontvangen. Hij stop pas met sturen als het TCP window volledig gebruikt is.

[alx]

Uit je vorige topic:

Soultaker schreef op dinsdag 19 september 2006 @ 19:44:
Ik kan me niet herinneren ooit meer dan 70% van de bandbreedte gehaald te hebben op een lokaal netwerk, dus ik denk dat je oorspronkelijke test al stuk was. Verder heb ik niet echt een idee wat er stuk gaat, maar als je met TCP nog wel dezelfde throughput haalt, is er weinig mis, denk ik. Dan moet je het probleem eerder in rare timing of rare fragmentatie zoeken.

Dit ken ik ook. Jij transfert ~70% van 100Mb/s beide kanten uit. Dat is zo'n 140 Mb/s. Klopt precies wat die tooltjes zeggen. Als je 1 verbinding gebruikt en tegelijkertijd verzend en ontvangt, kun je mss nog <1% verbetering halen; de ACKs kunnen dat meeliften bij beide verzenders.

Als je netwerk full-duplex werkt, heb je (vanaf TCP ~70% van) 100 Mb/s in beide richtingen.

[Gerco]

TrailBlazer schreef op woensdag 20 september 2006 @ 10:58:
wie zegt dat de server niet vast het volgende pakket stuurt voordat de pong van de voorgaande is ontvangen. Hij stop pas met sturen als het TCP window volledig gebruikt is.

In de TS staat:

Onze eigen applicatie stuurt een blok van 4KBytes naar de andere laptop. De andere laptop reageert hier direct op met een blok van 4KBytes. En dit ping pong effect gaat continu door.

De andere laptop reageert op de 'ping' met een 'pong', dat betekent dat hij eerst de data ontvangen moet hebben voor hij gaat sturen. Nu zou het natuurlijk wel kunnen dat hij begint met zijn 'pong' sturen zodra hij de eerste byte van 'ping' binnen heeft en dat zou hem sneller maken, maar nog steeds niet helemaal full-duplex.

[TrailBlazer]

Gerco schreef op woensdag 20 september 2006 @ 11:16:
[...]

In de TS staat:

[...]

De andere laptop reageert op de 'ping' met een 'pong', dat betekent dat hij eerst de data ontvangen moet hebben voor hij gaat sturen. Nu zou het natuurlijk wel kunnen dat hij begint met zijn 'pong' sturen zodra hij de eerste byte van 'ping' binnen heeft en dat zou hem sneller maken, maar nog steeds niet helemaal full-duplex.

ja dat klopt maar als de 2e ping kan wel verstuurd worden voordat de 1e pong ontvangen is. Je blijft pigns versturen zolang het aantal nog niet geacknowledgede aantal bytes boven je windowsize zit.

[Gerco]

TrailBlazer schreef op woensdag 20 september 2006 @ 11:32:
ja dat klopt maar als de 2e ping kan wel verstuurd worden voordat de 1e pong ontvangen is. Je blijft pigns versturen zolang het aantal nog niet geacknowledgede aantal bytes boven je windowsize zit.

Ik ging er vanuit dat beide computers hetzelfde deden. Dus computer 1 stuurt 'ping'. 2 wacht tot 'ping' is ontvangen en stuurt 'pong'. 1 wacht tot 'pong' is ontvangen en stuurt weer 'ping'.

Jij gaat blijkbaar uit van: 1 stuurt constant 'ping's. 2. reageert op elke 'ping' met 'pong'. 1 negeert 'pong's.

[TrailBlazer]

Gerco schreef op woensdag 20 september 2006 @ 12:11:
[...]

Ik ging er vanuit dat beide computers hetzelfde deden. Dus computer 1 stuurt 'ping'. 2 wacht tot 'ping' is ontvangen en stuurt 'pong'. 1 wacht tot 'pong' is ontvangen en stuurt weer 'ping'.

Jij gaat blijkbaar uit van: 1 stuurt constant 'ping's. 2. reageert op elke 'ping' met 'pong'. 1 negeert 'pong's.

ja daar ga ik inderdaad vanuit anders komt de TS nooit boven de 100 mb uit

[Wirf]

Verwijderd schreef op woensdag 20 september 2006 @ 10:50:
Okee, dat was onze eerste gedachte. Echter, waar blijft de resterende 60-80Mbit??? Is dit allemaal overhead? Dit was ook met name de reden dat we full duplex niet als oplossing hebben beschouwd. Is er een mogelijkheid om uit te zoeken hoeveel % er van de lijn daadwerkelijk gebruikt wordt? Om dus feitelijk te zien hoeveel % van de lijn uit data bestaat en hoeveel % er uit overhead bestaat (TCP protocol en dergelijke). Is hier een tool voor te vinden?

Ik durf te wedden dat 4 KB niet het meest optimale is om te versturen om hoge transfersnelheden te krijgen. Ik denk dat als je je pakketjes even groot maakt als het MTU dat dat al een heel stuk efficienter is.
Verder heb je overhead voor het TCP protocol, het IP protocol en het Ethernet protocol.
Ook zal je switch nog vertragend werken, de meeste van deze switchjes werken met een store-and-forward manier van werken, wat betekend dat je (ethernet!) pakketje eerst volledig ontvangen wordt en pas daarna verstuurd wordt. Dat heeft natuurlijk ook vertraging tot gevolg.

Dus: veel plekken waar je vertraging oploopt, 140 mbit/s is helemaal niet zo gek.