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
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
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?
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.
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.
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.
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?)
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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.