Throughput iperf Wifi TCP: 1 flusso vs flussi multipli?

In un test di velocità effettiva TCP iperf TCP, più flussi paralleli mi daranno una velocità maggiore di 1 flusso. Ho provato ad aumentare le dimensioni della finestra TCP, ma non riesco ancora a raggiungere il throughput massimo con un solo flusso. C'è qualcos'altro nel livello TCP che impedisce l'utilizzo dell'intera capacità di collegamento?

— elin05
fonte

Quanta differenza osservi? Idealmente, se un flusso TCP fornisce un throughput di T, due dovrebbero fornire singolarmente un throughput di T / 2 ciascuno.

— Manoj Pandey,

Si noti che la piena capacità di collegamento indipendentemente dal numero di flussi non sarà mai raggiunta. IPv4 con intestazioni minime [IP + TCP] produrrà un'efficienza del canale del 95% circa. Vedi l'eccellente pubblicazione Overhead di protocollo su sd.wareonearth.com/~phil/net/overhead .

— generalnetworkerror

@ManojPandey, non sono sicuro che stia vedendo un caso ideale ... soprattutto dal momento che sta usando il wifi ... Sospetto che abbia qualche perdita di pacchetti ...

— Mike Pennington,

TCP fa schifo tramite Wi-Fi, affrontalo. Se devi usarlo e stai vedendo perdite di pacchetti di livello 3, suggerirei di aumentare il numero massimo di tentativi di livello 2, poiché TCP non è progettato per gestire i collegamenti con perdita senza distruggere le prestazioni.

— BatchyX,

In un test di velocità effettiva TCP iperf TCP, più flussi paralleli mi daranno una velocità maggiore di 1 flusso. Ho provato ad aumentare le dimensioni della finestra TCP, ma non riesco ancora a raggiungere il throughput massimo con un solo flusso. C'è qualcos'altro nel livello TCP che impedisce l'utilizzo dell'intera capacità di collegamento?

Nella mia esperienza, se vedi risultati significativamente diversi tra 1 flusso TCP e più flussi TCP, il problema è normalmente la perdita di pacchetti; quindi "qualcos'altro" nel livello TCP è la ritrasmissione (a causa della perdita di pacchetti di livello inferiore).

Un esempio che ho elaborato per illustrare in che modo la perdita di pacchetti influisce sulla velocità del flusso singolo ...

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

Questa è una tabella che riassume i risultati del test di un test di 60 secondi iperftra un client e un server ... potresti vedere una piccola variazione nei risultati iperf dal jitter RTT (ovvero una deviazione standard RTT più alta); tuttavia, la differenza più significativa è arrivata quando ho simulato una perdita del 2% lasciando la scheda di rete cablata del client. 172.16.1.56 e 172.16.1.80 sono lo stesso laptop (con Ubuntu). Il server è 172.16.1.5, che esegue Debian. Ho usato netem sulla scheda di rete cablata client per simulare la perdita di pacchetti ...

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

MODIFICA per le risposte ai commenti :

Puoi spiegare cosa sta succedendo nell'ultimo scenario (1000BaseT, 5 flussi, perdita del 2,0%)? Anche se si verifica una perdita di pacchetti, il throughput totale è ancora saturo a 937 Mbits / sec.

La maggior parte delle implementazioni TCP riduce la finestra di congestione quando viene rilevata la perdita di pacchetti. Dato che stiamo usando netem per forzare la perdita di pacchetti del 2% dal client al server, alcuni dei dati del client vengono eliminati. L'effetto netto di netem in questo esempio è una velocità di trasmissione media a flusso singolo di 730 Mbps. L'aggiunta di più flussi significa che i singoli flussi TCP possono lavorare insieme per saturare il collegamento.

Il mio obiettivo è raggiungere la massima velocità TCP possibile tramite WiFi. A quanto mi risulta, dovrei aumentare il numero di flussi al fine di contrastare la riduzione della velocità di trasmissione causata dalla perdita di pacchetti. È corretto?

sì

Inoltre, a che punto troppi flussi inizieranno ad avere un impatto negativo sulla velocità effettiva? Ciò sarebbe causato da memoria e / o potenza di elaborazione limitate?

Non posso davvero rispondere senza ulteriori esperimenti, ma per i collegamenti 1GE non ho mai avuto problemi a saturare un collegamento con 5 flussi paralleli. Per darti un'idea di quanto sia scalabile TCP, i server Linux possono gestire oltre 1500 socket TCP simultanei nelle giuste circostanze. Questa è un'altra discussione SO che è rilevante per il ridimensionamento dei socket TCP simultanei, ma a mio avviso qualsiasi cosa sopra 20 socket paralleli sarebbe eccessiva se si sta semplicemente cercando di saturare un collegamento.

Devo avere un malinteso sul fatto che iperf usa la dimensione della finestra -w al massimo in quanto sembra che tu stia dicendo che è cresciuto oltre quel valore iniziale di 21K

Non ho usato iperf -w, quindi penso che ci sia un malinteso. Dal momento che hai così tante domande sul caso wifi, sto includendo un grafico wirehark del throughput TCP per il caso stream TCP TCP singolo.

Throughput a flusso singolo TCP TCP

Dati di test

Includo anche dati di prova grezzi nel caso in cui desideri vedere come ho misurato queste cose ...

802.11g, 1 flusso 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 flussi 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:~$

1000 Base, 1 flusso, perdita dello 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:~$

1000 Base, 5 flussi, perdita dello 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 stream, perdita del 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:~$

1000 Base, 5 flussi, perdita del 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:~$

Rimuovere la simulazione della perdita di pacchetti

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

— Mike Pennington
fonte

Puoi spiegare cosa sta succedendo nell'ultimo scenario (1000BaseT, 5 flussi, perdita del 2,0%)? Anche se si verifica una perdita di pacchetti, il throughput totale è ancora saturo a 937 Mbits / sec. Il mio obiettivo è raggiungere la massima velocità TCP possibile tramite WiFi. A quanto mi risulta, dovrei aumentare il numero di flussi al fine di contrastare la riduzione della velocità di trasmissione causata dalla perdita di pacchetti. È corretto? Inoltre, a che punto troppi flussi inizieranno ad avere un impatto negativo sulla velocità effettiva? Ciò sarebbe causato da memoria e / o potenza di elaborazione limitate?

— elin05,

@ elin05: L'uso di più flussi distribuisce la perdita di pacchetti su più flussi, quindi quando si verifica una perdita di pacchetti, solo un flusso ridurrà la dimensione della sua finestra TCP, lasciando inalterati gli altri flussi.

— BatchyX,

Il BDP 802.11g (54 Mbps) non richiede una dimensione della finestra di 54 KB con un ritardo di 8 ms (16 ms RTT / 2) per mantenere la pipa piena con i pacchetti in volo? Qual è la dimensione della finestra sul lato server?

— generalnetworkerror,

@generalnetworkerror, le finestre TCP non sono statiche ... cambiano in base alle esigenze del TCP ... durante tale acquisizione, la dimensione massima della finestra dichiarata dallo Tsunami era di 1177600 byte; La finestra media dello Tsunami era di 1045083 byte e la RTT media su quel test di 60 secondi era di 32,2 ms.

— Mike Pennington,

@MikePennington: Devo avere un malinteso sul fatto che iperf utilizzi le dimensioni della finestra -w al massimo in quanto sembra che tu stia dicendo che è cresciuto oltre quel valore iniziale di 21K.

— generalnetworkerror

Ecco il calcolo per il throughput massimo di un singolo flusso tcp.

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

Quindi hai un collo di bottiglia e la latenza gioca un ruolo importante.

— James.Birmingham
fonte

Probabilmente è dovuto a più processi vs un processo. con iperf 2.0.9 è possibile testarlo tramite -P 2 sul client. Questo forcherà due thread anziché uno. La maggior parte delle CPU moderne ha più core, quindi l'utilizzo di più thread sarà in grado di sfruttarli.

— rjmcmahon
fonte