Débit iperf TCP TCP: 1 flux vs plusieurs flux?

Dans un test de débit TCP iperf WLAN, plusieurs flux parallèles me donneront un débit supérieur à 1 flux. J'ai essayé d'augmenter la taille de la fenêtre TCP, mais je ne parviens toujours pas à atteindre le débit maximal avec un seul flux. Y a-t-il autre chose dans la couche TCP qui empêche l'utilisation de la pleine capacité de la liaison?

— elin05
source

Quelle différence observez-vous? Idéalement, si un flux TCP fournit un débit de T, alors deux devraient fournir individuellement un débit de T / 2 chacun.

— Manoj Pandey

Notez que la capacité de liaison complète quel que soit le nombre de flux ne sera jamais atteinte. IPv4 avec des en-têtes [IP + TCP] minimaux produira une efficacité de canal de ~ 95%. Voir l'excellente publication des frais généraux de protocole sur sd.wareonearth.com/~phil/net/overhead .

— generalnetworkerror

@ManojPandey, je ne suis pas sûr qu'il voit un cas idéal ... surtout depuis qu'il utilise le wifi ... Je soupçonne qu'il a une certaine perte de paquets ...

— Mike Pennington

TCP aspire le Wi-Fi, faites-le. Si vous devez l'utiliser et que vous voyez des pertes de paquets de couche 3, je suggérerais d'augmenter le nombre maximal de tentatives de couche 2, car TCP n'est pas conçu pour gérer les liens avec perte sans détruire les performances.

— BatchyX

Dans un test de débit TCP iperf WLAN, plusieurs flux parallèles me donneront un débit supérieur à 1 flux. J'ai essayé d'augmenter la taille de la fenêtre TCP, mais je ne parviens toujours pas à atteindre le débit maximal avec un seul flux. Y a-t-il autre chose dans la couche TCP qui empêche l'utilisation de la pleine capacité de la liaison?

D'après mon expérience, si vous voyez des résultats significativement différents entre 1 flux TCP et plusieurs flux TCP, le problème est normalement la perte de paquets; donc "quelque chose d'autre" dans la couche TCP est la retransmission (en raison de la perte de paquets de couche inférieure).

Un exemple que j'ai préparé pour illustrer comment la perte de paquets affecte le débit d'un seul flux ...

                   [Wifi||LAN-0.0%-Loss||LAN-2.0%-Loss]
+--------------+                                        +--------------+
|              |                                        |              |
| Thinkpad-T61 |----------------------------------------| Linux Server |
|              |                                        | Tsunami      |
+--------------+                                        +--------------+
iperf client             ------------------>            iperf server
                             Pushes data

Ceci est un tableau qui résume les résultats d'un test de 60 secondes iperfentre un client et un serveur ... vous pouvez voir une petite variation dans les résultats iperf de la gigue RTT (c'est-à-dire un écart-type RTT plus élevé); cependant, la différence la plus significative est survenue lorsque j'ai simulé une perte de 2% en laissant la carte réseau câblée du client. 172.16.1.56 et 172.16.1.80 sont le même ordinateur portable (exécutant Ubuntu). Le serveur est 172.16.1.5, exécutant Debian. J'ai utilisé netem sur la carte réseau câblée du client pour simuler la perte de paquets ...

Client IP       Transport    Loss     avg RTT    RTT StdDev    TCP Streams   Tput
-----------     ----------   ----     -------    ----------    -----------   ----------
172.16.1.56     802.11g      0.0%      0.016s          42.0              1     19.5Mbps
172.16.1.56     802.11g      0.0%      0.016s          42.0              5     20.5Mbps
172.16.1.80     1000BaseT    0.0%     0.0002s           0.0              1    937  Mbps
172.16.1.80     1000BaseT    0.0%     0.0002s           0.0              5    937  Mbps
172.16.1.80     1000BaseT    2.0%     0.0002s           0.0              1    730  Mbps <---
172.16.1.80     1000BaseT    2.0%     0.0002s           0.0              5    937  Mbps

MODIFIER les réponses aux commentaires :

Pouvez-vous expliquer ce qui se passe dans le dernier scénario (1000BaseT, 5 flux, perte de 2,0%)? Même s'il y a perte de paquets, le débit total est toujours saturé à 937 Mbits / sec.

La plupart des implémentations TCP réduisent leur fenêtre de congestion lorsqu'une perte de paquets est détectée. Puisque nous utilisons netem pour forcer la perte de paquets de 2% du client vers le serveur, certaines données du client sont supprimées. L'effet net de netem dans cet exemple est un débit de transmission moyen à un seul flux de 730 Mbps. L'ajout de plusieurs flux signifie que les flux TCP individuels peuvent fonctionner ensemble pour saturer le lien.

Mon objectif est d'atteindre le débit TCP le plus élevé possible sur le WiFi. Si je comprends bien, je devrais augmenter le nombre de flux afin de contrer la diminution du débit causée par la perte de paquets. Est-ce correct?

Oui

De plus, à quel moment trop de flux commenceront-ils à avoir un impact négatif sur le débit? Serait-ce dû à une mémoire et / ou une puissance de traitement limitées?

Je ne peux pas vraiment répondre à cela sans plus d'expériences, mais pour les liens 1GE, je n'ai jamais eu de problème pour saturer un lien avec 5 flux parallèles. Pour vous donner une idée de l’extensibilité de TCP, les serveurs Linux peuvent gérer plus de 1 500 sockets TCP simultanés dans les bonnes circonstances. C'est une autre discussion SO qui est pertinente pour la mise à l'échelle de sockets TCP simultanés, mais à mon avis, tout ce qui dépasse 20 sockets parallèles serait exagéré si vous essayez simplement de saturer un lien.

Je dois comprendre que iperf utilise au maximum la taille de la fenêtre -w car il semble que vous disiez qu'elle a dépassé cette valeur initiale de 21K

Je n'ai pas utilisé iperf -w, donc je pense qu'il y a un malentendu. Étant donné que vous avez tant de questions sur le boîtier Wi-Fi, j'inclus un graphique Wirehark du débit TCP pour le boîtier de flux TCP TCP unique.

Débit Wifi TCP unique

Données de test

J'inclus également des données de test brutes au cas où vous voudriez voir comment j'ai mesuré ces choses ...

802.11g, 1 flux TCP

mpenning@mpenning-ThinkPad-T61:~$ mtr --no-dns --report \
  --report-cycles 60 172.16.1.5
HOST: mpenning-ThinkPad-T61       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 172.16.1.5                 0.0%    60    0.8  16.0   0.7 189.4  42.0
mpenning@mpenning-ThinkPad-T61:~$

[mpenning@tsunami]$ iperf -s -p 9000 -B 172.16.1.5

mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9000 -t 60 -P 1
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9000
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  3] local 172.16.1.56 port 40376 connected with 172.16.1.5 port 9000
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.1 sec   139 MBytes  19.5 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$

802.11g, 5 flux TCP

[mpenning@tsunami]$ iperf -s -p 9001 -B 172.16.1.5

mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9001 -t 60 -P 5
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9001
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  3] local 172.16.1.56 port 37162 connected with 172.16.1.5 port 9001
[  5] local 172.16.1.56 port 37165 connected with 172.16.1.5 port 9001
[  7] local 172.16.1.56 port 37167 connected with 172.16.1.5 port 9001
[  4] local 172.16.1.56 port 37163 connected with 172.16.1.5 port 9001
[  6] local 172.16.1.56 port 37166 connected with 172.16.1.5 port 9001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.0 sec  28.0 MBytes  3.91 Mbits/sec
[  5]  0.0-60.1 sec  28.8 MBytes  4.01 Mbits/sec
[  4]  0.0-60.3 sec  28.1 MBytes  3.91 Mbits/sec
[  6]  0.0-60.4 sec  34.0 MBytes  4.72 Mbits/sec
[  7]  0.0-61.0 sec  30.5 MBytes  4.20 Mbits/sec
[SUM]  0.0-61.0 sec   149 MBytes  20.5 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$

1000BaseT, 1 flux, perte de 0,0%

mpenning@mpenning-ThinkPad-T61:~$ mtr --no-dns --report \
>   --report-cycles 60 172.16.1.5
HOST: mpenning-ThinkPad-T61       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 172.16.1.5                 0.0%    60    0.2   0.2   0.2   0.2   0.0
mpenning@mpenning-ThinkPad-T61:~$

[mpenning@tsunami]$ iperf -s -p 9002 -B 172.16.1.5

mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9002 -t 60 -P 1
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9002
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  3] local 172.16.1.80 port 49878 connected with 172.16.1.5 port 9002
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.0 sec  6.54 GBytes   937 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$

1000BaseT, 5 flux, perte de 0,0%

[mpenning@tsunami]$ iperf -s -p 9003 -B 172.16.1.5

mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9003 -t 60 -P 5
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9003
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  7] local 172.16.1.80 port 47047 connected with 172.16.1.5 port 9003
[  3] local 172.16.1.80 port 47043 connected with 172.16.1.5 port 9003
[  4] local 172.16.1.80 port 47044 connected with 172.16.1.5 port 9003
[  5] local 172.16.1.80 port 47045 connected with 172.16.1.5 port 9003
[  6] local 172.16.1.80 port 47046 connected with 172.16.1.5 port 9003
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-60.0 sec  1.28 GBytes   184 Mbits/sec
[  5]  0.0-60.0 sec  1.28 GBytes   184 Mbits/sec
[  3]  0.0-60.0 sec  1.28 GBytes   183 Mbits/sec
[  6]  0.0-60.0 sec  1.35 GBytes   193 Mbits/sec
[  7]  0.0-60.0 sec  1.35 GBytes   193 Mbits/sec
[SUM]  0.0-60.0 sec  6.55 GBytes   937 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$

1000BaseT, 1 flux, perte de 2,0%

mpenning@mpenning-ThinkPad-T61:~$ sudo tc qdisc add dev eth0 root netem corrupt 2.0%

mpenning@mpenning-ThinkPad-T61:~$ mtr --no-dns --report   --report-cycles 60 172.16.1.5
HOST: mpenning-ThinkPad-T61       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 172.16.1.5                 1.7%    60    0.2   0.2   0.2   0.2   0.0
mpenning@mpenning-ThinkPad-T61:~$

[mpenning@tsunami]$ iperf -s -p 9004 -B 172.16.1.5

mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9004 -t 60 -P 1
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9004
TCP window size: 42.0 KByte (default)
------------------------------------------------------------
[  3] local 172.16.1.80 port 48910 connected with 172.16.1.5 port 9004
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-64.1 sec  5.45 GBytes   730 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$

1000BaseT, 5 flux, perte de 2,0%

[mpenning@tsunami]$ iperf -s -p 9005 -B 172.16.1.5

mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9005 -t 60 -P 5
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9005
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  7] local 172.16.1.80 port 50616 connected with 172.16.1.5 port 9005
[  3] local 172.16.1.80 port 50613 connected with 172.16.1.5 port 9005
[  5] local 172.16.1.80 port 50614 connected with 172.16.1.5 port 9005
[  4] local 172.16.1.80 port 50612 connected with 172.16.1.5 port 9005
[  6] local 172.16.1.80 port 50615 connected with 172.16.1.5 port 9005
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.0 sec  1.74 GBytes   250 Mbits/sec
[  7]  0.0-60.0 sec   711 MBytes  99.3 Mbits/sec
[  4]  0.0-60.0 sec  1.28 GBytes   183 Mbits/sec
[  6]  0.0-60.0 sec  1.59 GBytes   228 Mbits/sec
[  5]  0.0-60.0 sec  1.24 GBytes   177 Mbits/sec
[SUM]  0.0-60.0 sec  6.55 GBytes   937 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$

Supprimer la simulation de perte de paquets

mpenning@mpenning-ThinkPad-T61:~$ sudo tc qdisc del dev eth0 root

— Mike Pennington
source

Pouvez-vous expliquer ce qui se passe dans le dernier scénario (1000BaseT, 5 flux, perte de 2,0%)? Même s'il y a perte de paquets, le débit total est toujours saturé à 937 Mbits / sec. Mon objectif est d'atteindre le débit TCP le plus élevé possible sur le WiFi. Si je comprends bien, je devrais augmenter le nombre de flux afin de contrer la diminution du débit causée par la perte de paquets. Est-ce correct? De plus, à quel moment trop de flux commenceront-ils à avoir un impact négatif sur le débit? Serait-ce dû à une mémoire et / ou une puissance de traitement limitées?

— elin05

@ elin05: L'utilisation de plusieurs flux répartit la perte de paquets sur plusieurs flux, donc lorsqu'une perte de paquets se produit, un seul flux réduira la taille de sa fenêtre TCP, laissant les autres flux inchangés.

— BatchyX

Le BDP 802.11g (54 Mbps) n'appelle-t-il pas une taille de fenêtre de 54 Ko avec un délai de 8 ms (16 ms RTT / 2) pour garder le tuyau plein avec des paquets en vol? Quelle est la taille de la fenêtre côté serveur?

— generalnetworkerror

@generalnetworkerror, les fenêtres TCP ne sont pas statiques ... elles changent en fonction des besoins de TCP ... pendant cette capture, la taille de fenêtre maximale annoncée par le tsunami était de 1177600 octets; La fenêtre moyenne du tsunami était de 1045083 octets et le RTT moyen sur ce test de 60 secondes était de 32,2 ms.

— Mike Pennington

@MikePennington: Je dois comprendre que iperf utilise la taille de la fenêtre -w au maximum car il semble que vous disiez qu'elle a augmenté au-delà de cette valeur initiale de 21K.

— generalnetworkerror

Voici le calcul du débit maximal d'un seul flux TCP.

(TCP Window [bytes]/RTT[seconds]) * 8 [bits/byte] = Max single tcp throughput in (bps)

Vous avez donc un goulot d'étranglement et la latence joue un rôle important.

— James.Birmingham
source

C'est probablement dû à plusieurs processus vs un seul processus. avec iperf 2.0.9, on peut tester cela via -P 2 sur le client. Cela va bifurquer deux threads au lieu d'un. La plupart des processeurs modernes ont plusieurs cœurs, donc l'utilisation de plusieurs threads pourra les exploiter.

— rjmcmahon
source