meilleures performances TCP sur un «réseau à retard élevé»

J'essaie d'améliorer mon débit TCP sur un «réseau à retard élevé» entre des machines Linux.

Je mets tcp_mem, tcp_wmemet tcp_rmemsur "8192 7061504 7061504".
Je mis rmem_max, wmem_max, rmem_defaultet wmem_defaultà « 7061504 ».
Je mets netdev_max_backloget txqueuelenà 10000.
Je mets tcp_congestion_controlà «évolutif».

J'utilise «nist» (cnistnet) pour simuler un retard de 100 ms, et le BW que j'atteins est d'environ 200 Mbps (sans délai j'atteins environ 790mbps).

J'utilise iperf pour effectuer les tests et TCPTrace pour analyser les résultats, et voici ce que j'ai obtenu:

Côté récepteur:
max win adv: 5294720 octets
avg win adv: 5273959 octets
sack pkts sent: 0

Côté émetteur:
octets de données réels: 3085179704
octets de données rexmt: 9018144 débit
maximum: 5294577 octets débit
moyen: 3317125 octets
RTT minimum: 19,2 ms
RTT maximum: 218,2 ms
RTT moyen: 98,0 ms

Pourquoi j'atteins seulement 200 Mbps? Je soupçonne que le «owin» a quelque chose à voir avec cela, mais je ne suis pas sûr (ces résultats sont d'un test de 2 minutes. Un test de 1 minutes avait un «owin moyen» de 1552900)…

Ai-je tort de m'attendre à un débit de près de 790 Mbps même si le délai est de 100 ms?

(J'ai essayé d'utiliser de plus grands nombres dans les configurations de fenêtres mais cela ne semblait pas avoir d'effet)

Il s'agit d'un problème TCP commun appelé «Long Fat Pipe». Si vous recherchez cette phrase et TCP sur Google, vous trouverez de nombreuses informations sur ce problème et les solutions possibles.

Ce fil a un tas de calculs et de suggestions sur le réglage de la pile TCP Linux pour ce genre de chose.

Le site

http://www.psc.edu/networking/projects/tcptune/

mentionne que, comme Linux de nos jours ajuste automatiquement les paramètres TCP, jouer avec les valeurs n'améliorera probablement pas les choses.

Cela étant dit, peut-être que 100 ms avec une large bande passante (au moins 790 Mbps) pourraient conduire à un énorme BDP, donc peut-être que l'autoréglage décide que quelque chose ne va pas et ne va pas assez loin.

Essayez de définir la taille de la fenêtre iperf pour vraiment déterminer le produit de retard de bande passante de ce lien. Donc moy. RTT * 1 Gbps devrait vous donner approximativement 10 Mo. Voyez si cela améliore les choses.

La seule façon de vraiment comprendre ce qui se passe est d'obtenir plus de données - sinon vous devinez ou demandez à d'autres de deviner. Je recommande d'obtenir une vue au niveau du système (CPU, mémoire, interruptions, etc.) avec sarle iostatpackage. En outre, vous devriez obtenir un vidage de paquets avec Wireshark ou tcpdump. Vous pouvez ensuite utiliser Wireshark pour l'analyser car il dispose de nombreux outils pour cela. Vous pouvez représenter graphiquement la taille de la fenêtre au fil du temps, la perte de paquets, etc.

Même une petite perte de paquets sur une liaison à latence élevée a tendance à réduire considérablement la bande passante. Bien que simulé - c'est un peu étrange. De nombreux petits paquets peuvent également provoquer de fortes interruptions (même si elles peuvent également être simulées?).

Donc, en bref, obtenez TCPDump et Sar pour voir ce qui se passe au niveau des paquets et avec les ressources de votre système.

De combien de mémoire cette machine dispose-t-elle? Les tcp_memparamètres semblent être fous, il a configuré 28 Go (7061504 * 4 Ko) pour les données TCP dans le monde. (Mais ce n'est pas votre problème de performance car vous n'atteignez probablement pas cette limite lors d'un test de quelques sockets. Je voulais juste le mentionner car la définition de tcp_mem sur tcp_xmem montre une conception erronée très courante).

Le 7 Mo que vous avez configuré par défaut semble correct. Le maximum peut cependant monter beaucoup plus haut sur les gros tuyaux à retard. Pour les tests, j'utiliserais 64 Mo comme nombre maximal pour tcp_wmemet tcp_rmem, alors vous pouvez exclure que c'est votre facteur limitant. (Cela gonfle vos tampons, donc cela ne fonctionne que si vous avez une concurrence limitée et que la connexion a une faible gigue et des chutes).