Iperf: Messung der Netzwerkgeschwindigkeit

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

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?

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

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

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

mit ifconfig oder ip die mtu anpassen?

Mit dem Parameter -l funktioniert es nun.

iperf -s -u -p 42000 -l 24

Vielen Dank!

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

An Deinem System stimmt was ganz gehörig nicht.

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.