Contrôle de congestion TCP pour un réseau 10 GbE à faible latence -> 1 GbE?

J'ai un serveur avec une connexion 10GbE à un commutateur et 10 clients chacun avec une connexion 1GbE au même commutateur.

En exécutant nuttcp en parallèle sur chacun des clients, je peux pousser 10 flux TCP de données vers le serveur simultanément à une vitesse proche du fil (c'est-à-dire un peu moins de 100 mégaoctets par seconde à partir des 10 clients simultanément).

Cependant, lorsque j'inverse la direction et envoie des données du serveur aux clients - c'est-à-dire, 10 flux TCP, un allant à chaque client - les retransmissions TCP montent en flèche et les performances chutent à 30, 20, voire 10 mégaoctets par seconde. par client. Je veux obtenir ces chiffres, car ce modèle de trafic est représentatif de certaines applications qui m'intéressent.

J'ai vérifié que mon serveur est capable de saturer une liaison 10 GbE en effectuant la même expérience sur une connexion 10 GbE à un serveur similaire. J'ai vérifié qu'il n'y a aucune erreur sur aucun de mes ports.

Enfin, lorsque je force (limite) la taille de la fenêtre TCP du récepteur, je peux obtenir une bande passante un peu plus élevée (30 à 40 mégaoctets / s); et si je le serre extrêmement bas, je peux ramener les retransmissions à zéro (avec une bande passante ridiculement faible).

Ainsi, je suis raisonnablement sûr de dépasser les tampons de mon commutateur, ce qui entraîne une perte de paquets en raison de la congestion. Cependant, je pensais que le contrôle de la congestion de TCP était censé gérer cela correctement, se stabilisant finalement à quelque chose au-dessus de 50% de la vitesse du fil.

Ma première question est donc très simple: quel algorithme de contrôle de congestion TCP conviendrait le mieux à ma situation? Il y en a une tonne disponible, mais ils semblent principalement cibler les réseaux avec perte ou les réseaux à haute latence et à large bande passante ou les réseaux sans fil ... Aucun d'entre eux ne s'applique à ma situation.

Deuxième question: puis-je essayer autre chose?

linux networking tcp

— Nemo
source

Il serait utile de savoir quel modèle de commutateur. Différents commutateurs gèrent la mise en file d'attente de différentes manières et aideraient à affiner une solution.

— scottm32768

Différents commutateurs ont également des tailles de tampon différentes, donc la connaissance du modèle de commutateur aiderait à éliminer les problèmes matériels de votre problème.

— cpt_fink

En outre, les modèles de carte réseau, les pilotes, la version Linux, le noyau, la distribution, etc. Mes réponses pour une carte réseau Myricom ou Solarflare avec un Cisco 4900M seraient différentes d'un commutateur Dell Powerconnect et des cartes réseau Intel.

— ewwhite

Vous voudriez un algorithme où la taille de la fenêtre ne soit pas considérablement réduite en cas de perte de paquet. C'est la baisse drastique de la taille de la fenêtre qui se traduit par la baisse soudaine du débit avec le trafic TCP.
Si votre commutateur et votre serveur prennent en charge le contrôle de flux, essayez d'activer le contrôle de flux. La façon dont cela fonctionne dépend presque entièrement du silicium et du micrologiciel du commutateur. Fondamentalement, le commutateur détectera la congestion de sortie sur le port connecté à un client, déterminera d'où proviennent les paquets et enverra des trames de contrôle de flux hors du port d'entrée (c'est-à-dire au serveur). Si le serveur comprend les trames de contrôle de flux, cela réduira la vitesse de transmission. Si tout fonctionne bien, vous obtiendrez un débit optimal avec pratiquement zéro perte de paquets sur le tampon de sortie du commutateur.

— wookie919
source