TCP-Überlastungskontrolle für 10-GbE-Netzwerk mit geringer Latenz -> 1-GbE-Netzwerk?

Ich habe einen Server mit einer 10-GbE-Verbindung zu einem Switch und 10 Clients mit jeweils einer 1-GbE-Verbindung zu demselben Switch.

Wenn ich nuttcp parallel auf jedem der Clients ausführe, kann ich 10 TCP-Datenströme gleichzeitig mit nahezu Drahtgeschwindigkeit (dh knapp 100 Megabyte pro Sekunde von allen 10 Clients gleichzeitig) auf den Server übertragen.

Wenn ich jedoch die Richtung umkehre und Daten vom Server an die Clients sende - dh 10 TCP-Streams, von denen einer an jeden Client geht -, steigt die TCP-Neuübertragung sprunghaft an und die Leistung sinkt auf 30, 20 oder sogar 10 Megabyte pro Sekunde pro Kunde. Ich möchte diese Zahlen ermitteln, da dieses Verkehrsmuster für bestimmte Anwendungen repräsentativ ist, die mir wichtig sind.

Ich habe überprüft, ob mein Server eine 10-GbE-Verbindung sättigen kann, indem ich dasselbe Experiment über eine 10-GbE-Verbindung zu einem ähnlichen Server durchgeführt habe. Ich habe überprüft, dass an keinem meiner Ports Fehler vorliegen.

Wenn ich die TCP-Fenstergröße des Empfängers zwangsweise festklemme (einschränke), kann ich die Bandbreite etwas höher einstellen (30-40 Megabyte / s). und wenn ich es extrem niedrig klemme, kann ich die Neuübertragungen auf Null bringen (mit der lächerlich niedrigen Bandbreite).

Daher bin ich ziemlich sicher, dass ich die Puffer in meinem Switch überlaufe, was zu einem Paketverlust aufgrund einer Überlastung führt. Ich dachte jedoch, dass die Überlastungskontrolle von TCP dies gut bewältigen sollte und sich schließlich bei etwas über 50% der Drahtgeschwindigkeit stabilisierte.

Meine erste Frage ist also sehr einfach: Welcher TCP-Überlastungskontrollalgorithmus ist für meine Situation am besten geeignet? Es gibt eine Menge davon, aber sie scheinen hauptsächlich auf verlustbehaftete Netzwerke oder Netzwerke mit hoher Bandbreite und hoher Latenz oder drahtlose Netzwerke ausgerichtet zu sein ... Nichts davon trifft auf meine Situation zu.

Zweite Frage: Kann ich noch etwas ausprobieren?

linux networking tcp

— Nemo
quelle

Es wäre hilfreich zu wissen, welches Switch-Modell. Verschiedene Switches behandeln Warteschlangen auf unterschiedliche Weise und würden helfen, eine Lösung einzugrenzen.

— Scottm32768

Außerdem haben verschiedene Switches unterschiedliche Puffergrößen. Wenn Sie also das Switch-Modell kennen, können Sie Hardwareprobleme aus Ihrem Problem entfernen.

— cpt_fink

Auch die NIC-Modelle, Treiber, Linux-Version, Kernel, Distribution usw. Meine Antworten für eine Myricom- oder Solarflare-NIC mit einem Cisco 4900M würden sich von einem Dell Powerconnect-Switch und Intel-NICs unterscheiden.

— ewwhite

Sie möchten einen Algorithmus, bei dem die Fenstergröße bei einem Paketverlust nicht drastisch reduziert wird. Es ist der drastische Rückgang der Fenstergröße, der zu einem plötzlichen Rückgang des Durchsatzes beim TCP-Verkehr führt.
Wenn Ihr Switch und Ihr Server die Flusskontrolle unterstützen, aktivieren Sie die Flusskontrolle. Wie gut dies funktioniert, hängt fast ausschließlich vom Silizium und der Firmware des Switch ab. Grundsätzlich erkennt der Switch eine Überlastung des Ausgangs an dem mit einem Client verbundenen Port, ermittelt, woher die Pakete stammen, und sendet Flusssteuerungsrahmen über den Eingangsport (dh zurück zum Server). Wenn der Server Flusssteuerungsrahmen versteht, wird die Übertragungsgeschwindigkeit verringert. Wenn alles gut funktioniert, erhalten Sie einen optimalen Durchsatz, wobei praktisch keine Paketverluste im Ausgangspuffer des Switch auftreten.

— wookie919
quelle