Débit cumulé de plusieurs connexions (Linux)

Question

Pourquoi plusieurs connexions provenant du même hôte obtiennent-elles un meilleur débit que plusieurs connexions provenant d'hôtes différents?

Je suppose que c'est quelque chose lié au noyau (Linux) mais une confirmation aiderait beaucoup.

Plus de détails J'ai 1 processus de réception, appelons-le R. Il accepte les connexions entrantes et reçoit des données en utilisant select().

J'ai 3 processus d'envoi S1, S2, S3. Ils se connectent à R et envoient des données à un débit fixe, c'est-à-dire 200 Mbits par seconde chacun.

Si S1, S2 et S3 sont sur la même machine, j'obtiens de meilleurs résultats que d'avoir chacun d'entre eux sur une machine différente. (R se trouve dans les deux cas sur une autre machine)

Exemple: R sur host0, S1, S2, S3 sur host2, R reçoit à

R 600Mbit/s sur host0, S1 sur host1, S2 sur host2 , S3 sur host3, R reçoit à 480Mbit/s

Cela semble contre-intuitif pour moi, je m'attendais à l'opposé puisque dans le second cas, les expéditeurs n'ont pas à partager la carte réseau et le processeur (ce qui n'est pas attendu processeur ou carte réseau à goulot d'étranglement ...)

[Les hôtes ci-dessus sont des nœuds dans un cluster Linux avec un commutateur Gigabit full-duplex dédié. Ils exécutent 2.6.24-24-générique (le dernier Ubuntu je devine)]

Answer 1

C'est probablement parce que quand les expéditeurs sont tous sur une machine, les paquets sortants sont tous joliment mis en file d'attente et envoyés un-à-temps (juste en vertu du fait qu'ils passent tous par un NIC).

Alors que dans le cas des expéditeurs multiples, deux machines envoient souvent des paquets en même temps, et il appartient ensuite au commutateur réseau de les mettre en file d'attente. Cela se manifestera à l'envoi TCP comme une latence nerveuse - parfois un paquet sera passé directement au récepteur, d'autres fois il devra attendre un ou deux paquets des autres expéditeurs dans les files d'attente de commutation. Je pense que la gigue de latence seule suffirait à faire chuter votre bande passante - rappelez-vous que pour supporter 200mbps avec des fenêtres TCP standard, vous avez besoin d'un temps de propagation aller-retour minimum de 2.6ms, ce qui est assez serré.