J'ai pas regardé le CPU, c'est vrai que c'est intéressant pour voir le déchargement des opérations TCP/IP vers la carte réseau. Je voulais surtout voir si il y avait des différences de montée en débit. Le noyau 2.6.24 est systématiquement en retrait, mais cela reste un petit écart de performance (le protocole de congestion TCP n'est pas le même).

LRO (large-receive-offload) pourquoi il faut le mettre à off ?

J'ai cherché sans sucés de la documentation sur toutes ces options.

Dans le post TCP offload engine - Segmentation réalisée par la carte réseau, j'ai réalisé un tableau avec les options activées en fonction de la carte réseau utilisée. GRO (generic-receive-offload) est toujours on sauf sur les carte vraiment bas de gamme (VIA Technologies, Inc. VT6102 [Rhine-II] ou Broadcom Corporation BCM4401-B0 100Base-TX).

Dans certains cas (TCP ACK Suppression activé sur des box Docsis, ou certains ONT Orange), j'ai noté une baisse importante de performance en désactivant scatter-gather et un gain de performance en désactivant tcp-segmentation-offload et generic-segmentation-offload.

Comme tu peux le voir, les autres options ont aussi des forts impacts sur le WAN (importantes dès que le ping bout en bout dépasse les 10ms) :

Désactiver ce qui fait chuter le débit avec "TCP ACK Supression" activé sur une box : ethtool -K eth1 tso off gso off
tcp-segmentation-offload et generic-segmentation-offload chacun séparèment ou activé tous les deux font chuter fortement le débit avec TCP ACK Supression.
Au contraire scatter-gather permet de gagner du débit avec "TCP ACK Supression" activé.
- TOE entièrement activé (défaut) : 3 min 13 secondes pour télécharger le fichier test
- TOE entièrement dés-activé : 56 secondes pour télécharger le fichier test
- Tout désactivé sauf tx-checksumming et scatter-gather : 33 secondes pour télécharger le fichier test
- Seul tcp-segmentation-offload et generic-segmentation-offload désactivé : 33 secondes pour télécharger le fichier test

A noter qu'avec "TCP ACK Supression" désactivé ou qui n'existe pas (cas des majorités des box) on a :
- TOE entièrement activé (défaut) : 21 secondes pour télécharger le fichier test
- TOE entièrement dés-activé : 49 secondes pour télécharger le fichier test
- Tout désactivé sauf tx-checksumming et scatter-gather : 32 secondes pour télécharger le fichier test
- Seul tcp-segmentation-offload et generic-segmentation-offload désactivé : 32 secondes pour télécharger le fichier test

Si tu trouves de la documentation sur ces options, je suis preneur.

Les différences peuvent être assez impressionnantes (débit variant de 1 à 10 pour des ping important). A ce que j'ai compris, il est difficile d'avoir un système efficace avec tous les types de réseaux, notamment la 3G/4G, qui perdent des paquets sans que cela signifie nécessairement qu'il y a une congestion. Normalement le protocole de congestion Reno n'est pas bon pour les connexions qui passent par onde radio, mais je n'ai pas vérifié.

Pourquoi les réseaux 3G/4G ne retransmettent pas les paquets perdus?

Si, il y a bien un mécanisme de retransmission, mais jusqu'à un certain point seulement. Il est quand même assez fréquent, en déplacement, avec un téléphone, de perdre temporairement la connexion radio (une fraction de seconde), à cause d'un obstacle, d'une réception difficile. Quand on entend mal son correspondant sur un téléphone portable, on est exactement dans cette situation. Le réseau ne tente de retransmettre les paquets que si les paquets ne sont pas trop anciens, sinon, ils sont droppés tout simplement, et c'est normal.

Leon.

Pour satisfaire ma trop grande curiosité, est-il possible d'essayer avec nginx ?