Forum: PC-Programmierung Iperf: Messung der Netzwerkgeschwindigkeit


von Tester (Gast)


Lesenswert?

Guten Morgen,

für die Messung der Netzwerkgeschwindigkeit wird das Tool Iperf 
eingesetzt.
Nach dem ersten Datentransfer von Client zu Server sendet der Server 
eine Bestätigung mit der Länge von 1470 Bytes. Diese Größe kann das 
System nicht verarbeiten. Ist es möglich diese Größe auf 200 Bytes zu 
senken?

UDP-Client:
iperf -u -c 192.168.0.2 - p 42000 -l 24

UDP-Server:
iperf -s -u -p 42000

von Tester (Gast)


Lesenswert?

Gibt es noch ein anderen Programm womit man die Netzwerkgeschwindigkeit 
messen kann?

von System (Gast)


Lesenswert?

Was ist das für ein "System", daß die vom IEEE Standard geforderten 1500 
Bytes pro Frame nicht abkann? Von Jumbo Frames mit größer 1500 Bytes 
ganz zu schweigen. Was für einen Scheissendreck testest du denn da?

von Tester (Gast)


Lesenswert?

Ok das bringt mir jetzt auch nicht weiter. Gibt es da eine Möglichkeit 
die Größe zu verändern oder nicht.

von Tester (Gast)


Lesenswert?

--> Ethernet --> Umsetzer --> Kanal --> Umsetzer --> Ethernet

<-- Ethernet <-- Umsetzer <-- Kanal <-- Umsetzer <-- Ethernet

von Εrnst B. (ernst)


Lesenswert?

Tester schrieb:
> Gibt es da eine Möglichkeit
> die Größe zu verändern oder nicht.

Mal versucht, dem iperf-Server auch einen "-l 24" -Parameter zu 
verpassen?

von blubb (Gast)


Lesenswert?

mit ifconfig oder ip die mtu anpassen?

von Tester (Gast)


Lesenswert?

Mit dem Parameter -l funktioniert es nun.

iperf -s -u -p 42000 -l 24

Vielen Dank!

von radiostar (Gast)


Lesenswert?

Tester schrieb:
> 1470 Bytes. Diese Größe kann das
> System nicht verarbeiten

An Deinem System stimmt was ganz gehörig nicht.

von S. R. (svenska)


Lesenswert?

Naja, vielleicht ist die "Umsetzer - Kanal - Umsetzer"-Strecke auch ein 
SLIP-Tunnel mit einer MTU von maximal 576 Bytes oder so. PPPoE hat auch 
nur eine MTU von 1492, trotz Ethernet.

Das Stichwort ist MTU, den Rest muss der TO selbst erledigen.

von iperfer (Gast)


Lesenswert?

Ja, ein Stichwort ist MTU, das zweite der -l Parameter bei iperf. Laut 
iperf 1.70 Helptext "length of buffer to read or write (default 8 KB)".

Jetzt tauchen mehrere Fragen auf: Was will man mit -l 24 testen? Wie 
schnell TCP Quittungen übers Netz laufen könnten? Denn die dürften etwa 
die gleiche Länge haben wie UDP-Pakete mit 24 Byte Daten. Oder den 
Unterscheid mit -l 24 (24 Datenbyte) und ohne -l (8k Datenbyte?) oder 
vielleicht doch die vorhandene Bandbreite?

In der Behandlung der iperf Default-Einstellung und UDP ist das 
Geheimnis versteckt und möglicherweise auch noch in der iperf 
Versionsnummer :-).

8k können natürlich nicht auf einmal gesendet werden. Also müssen aus 
den 8k Byte passende Datenpakete gemacht werden, die über’s Netz 
verschickt werden können. Bei der Default-Einstellung, also ohne Angabe 
von -l, sendet iperf die Daten in "passenden" Paketen mit gesetztem 
DF-Bit (Don’t fragment). Bei Angabe von -l sendet iperf Pakete, die 
genau die bei –l angegebene Menge Datenbytes enthalten und zwar ohne 
DF-Bit. Die Pakete können also fragmentiert werden.

Wenn das iperf des TO so arbeitet wie mein 1.70, dann hat der TO 52 Byte 
lange IP Pakete (20+8+24) ohne DF-Bit zum iperf Server geschickt. Das 
hat kein Problem gegeben. Beim Server war der Parameter -l nicht 
angegeben, also hat der versucht seine Datenpakete in "passender" Größe 
mit gesetztem DF-Bit zu verschicken. Das hat scheint’s nicht geklappt.

Warum? Weil die Größe der Pakete doch nicht passend war. Wie soll er die 
auch herausfinden können? Das ist das Thema MTU. Die lässt sich bei UDP 
nicht in Zusammenarbeit mit dem (entfernten) Kommunikationspartner 
klären. Also nimmt man die eigene MTU als maximale Paketgröße. Wenn dann 
aber das DF-Bit gesetzt ist, kann es passieren, dass die UDP-Pakete 
nicht ankommen. Und das ist wohl auch passiert.

Das -l 24 hat das Problem gelöst, weil der Server dann auch nur 52 Byte 
lange IP Pakete erzeugt hat. Möglicherweise hätte aber auch -l 10k 
funktioniert.

von Konrad S. (maybee)


Lesenswert?

Mal nebenbei eine Frage: Weshalb ist es interessant, den UDP-Durchsatz 
eines Netzwerks zu kennen? (Welche Dienste setzen UDP für den Transport 
großer Datenmengen ein?)

von Ralf D. (doeblitz)


Lesenswert?

Konrad S. schrieb:
> Mal nebenbei eine Frage: Weshalb ist es interessant, den UDP-Durchsatz
> eines Netzwerks zu kennen? (Welche Dienste setzen UDP für den Transport
> großer Datenmengen ein?)

z.B. Mediastreaming

von Konrad S. (maybee)


Lesenswert?

Ralf D. schrieb:
> z.B. Mediastreaming

Ah, OK, danke. Zuhause nutze ich da nur "video on demand" und kann bei 
TCP bleiben. So groß ist die Familie nicht, dass ich da Multicast 
einsetzen muss.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.