Performance Routing vs Switching auf PC-Hardware

[wanne]

Win client mit iperf über 100 Mbps Switch an Linux-VM:

Ich sehe da vor allem einen schlechten TCP Stack auf Serverseite. Deswegen Bencharke ich lieber mit curl und nginx oder so statt mit irgend welchen tools, die root rechte brauchen und dann an irgend welchen Schrauben drehen, an die andere gar nicht ran kommen.
Ein besserer tcp stack ACKed nicht jedes Paket.
hier ein download vom des nvidia-Treibers netcup debian Mirror 80MBit/s Anbindung.
>5300Pakete hin 288-Pakete zurück (Und da sind nicht nur ACKs sonder auch noch ARP und ähnlicher kleiner "Müll" mit drin.) durchschnittliche Paketgröße ~1400Byte.
Auf 20 Daten-Pakete kam etwa ein ACK.
Bischen größere Datei und bisschen mehr Bandbreite und man merkt den Unterschied zu 1500byte nicht mehr. (Zumal Ethernet ja auch noch etwas größere Pakete zulässt.)
Das ist eine realitätsnahe Anwendung.

[dufty2]

Ich sehe da vor allem einen schlechten TCP Stack auf Serverseite.

Der war gut
Die Linux-VM ist ein Debian jessie. Bei iperf/iperf3 schickt übrigens der Client die Daten, der Server ACKed nur (in der Default-Einstellung).

Deswegen Bencharke ich lieber mit curl und nginx oder so statt mit irgend welchen tools, die root rechte brauchen und dann an irgend welchen Schrauben drehen, an die andere gar nicht ran kommen.

Der war gut
Wer Port 80/443 benutzen will, braucht root/admin-Rechte, wohingegen iperf3 Port 5201 auf Serverseite benutzt und der iperf3-client natürlich auch high ports.
Das open-source iperf/iperf3 wird auch im professionellen Bereich benutzt, wenn es mal schnell gehen soll (und die Firmenfirewalls mitspielen).

Ein besserer tcp stack ACKed nicht jedes Paket.

Der war gut
Delayed ACK ist bei debian aktiv und daher wird bei jedem 2. Paket geACKed (deshalb auch die Paket-Verteilung 2:1), was dem Standard entspricht.

hier ein download vom des nvidia-Treibers netcup debian Mirror 80MBit/s Anbindung.
>5300Pakete hin 288-Pakete zurück (Und da sind nicht nur ACKs sonder auch noch ARP und ähnlicher kleiner "Müll" mit drin.) durchschnittliche Paketgröße ~1400Byte.
Auf 20 Daten-Pakete kam etwa ein ACK.

Mach mal einen tcpdump

Code: Alles auswählen

# tcpdump host 46.38.225.104 -w a.pcap

während Deines nvida-Treiber downloads, stell ihn öffentlich zur Verfügung und ich schau ihn mir mal an.

[dufty2]

Und die neuen Customer-WLAN-Router kriegen jetzt Probleme: 1 GBit/s reicht nicht mehr für den Access der neuesten WLAN-Technologien AC3200 als Summe von 2 oder 3 Bändern. Für die Switchports sowieso noch nie. Zwischen CPU und Switch-Trunk leider nur 1 Gbit/s.

Denke nicht, das es (derzeit) zu Problemen kommt.
Richtig ist, dass bei vielen HeimRouter zwischen Switch(Chip) und CPU nur 1 x 1 Gbps (machmal 2 x 1) liegen, aber - wenn ich es jetzt richtig verstanden habe - ist bei diesem Asus RT-AC3200 Tri-Band die CPU im Switchchip mit integriert.
Daher könnte man bei einem "Bonding" von wlan0/1/2 auf ( 1,3 + 1,3 + 0,6 = 3,2 ) Gbps kommen, für die man dann die 4 LAN-ports als Bond bräuchte. Das sind aber theoretische Angaben, praktisch wohl eher ( 0,45 + 0,45 + 0,1 = 1 ) Gbps.
Dann reicht ein 1 Gbps LAN Port wieder

[BenutzerGa4gooPh]

Richtig ist, dass bei vielen HeimRouter zwischen Switch(Chip) und CPU nur 1 x 1 Gbps (machmal 2 x 1) liegen, aber - wenn ich es jetzt richtig verstanden habe - ist bei diesem Asus RT-AC3200 Tri-Band die CPU im Switchchip mit integriert.

Geil, wieder was ganz neues, du hast Recht.
http://www.smallnetbuilder.com/wireless ... r-reviewed

Ansonsten meinte ich mit "Problemen" mehr die Marketing-Strategen denn die Anwender. Keiner wird wohl praktisch die beworbenen Bandbreiten erzielen - aber ist doch niedlich, wie Marketing mit technischen Grenzen umgeht ...