Rendimiento de TCP TCP iperf: ¿1 flujo versus múltiples flujos?

12

En una prueba de rendimiento WLAN iperf TCP, múltiples flujos paralelos me darán un mayor rendimiento que 1 flujo. Intenté aumentar el tamaño de la ventana TCP, pero aún no puedo lograr el rendimiento máximo con solo 1 flujo. ¿Hay algo más en la capa TCP que impida que se use toda la capacidad del enlace?

wireless  ipv4  tcp  testing  iperf 
— elin05
fuente
¿Cuánta diferencia observas? Idealmente, si un flujo TCP proporciona un rendimiento de T, entonces dos deberían proporcionar individualmente un rendimiento de T / 2 cada uno.
— Manoj Pandey
Tenga en cuenta que nunca se alcanzará la capacidad total del enlace, independientemente del número de secuencias. IPv4 con encabezados mínimos [IP + TCP] producirá ~ 95% de eficiencia de canal. Vea la excelente publicación de protocolo de gastos generales en sd.wareonearth.com/~phil/net/overhead .
— generalnetworkerror
@ManojPandey, no estoy seguro de que esté viendo un caso ideal ... especialmente porque está usando wifi ... Sospecho que tiene una pérdida de paquetes ...
— Mike Pennington
TCP apesta a través de Wi-Fi, lidiar con eso. Si tiene que usarlo y ve pérdidas de paquetes en la capa 3, sugeriría aumentar el recuento máximo de reintentos en la capa 2, ya que TCP no está diseñado para manejar enlaces con pérdida sin destruir el rendimiento.
— BatchyX

Respuestas:

14

En una prueba de rendimiento WLAN iperf TCP, múltiples flujos paralelos me darán un mayor rendimiento que 1 flujo. Intenté aumentar el tamaño de la ventana TCP, pero aún no puedo lograr el rendimiento máximo con solo 1 flujo. ¿Hay algo más en la capa TCP que impida que se use toda la capacidad del enlace?

En mi experiencia, si ve resultados significativamente diferentes entre 1 flujo TCP y múltiples flujos TCP, el problema es normalmente la pérdida de paquetes; entonces el "algo más" en la capa TCP es la retransmisión (debido a la pérdida de paquetes de la capa inferior).

Un ejemplo que preparé para ilustrar cómo la pérdida de paquetes afecta el rendimiento de una sola secuencia ...

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

Esta es una tabla que resume los resultados de una prueba de 60 segundos iperfentre un cliente y un servidor ... es posible que vea una pequeña variación en los resultados de iperf del jitter RTT (es decir, una desviación estándar RTT más alta); Sin embargo, la diferencia más significativa se produjo cuando simulé una pérdida del 2% dejando al cliente con cable NIC. 172.16.1.56 y 172.16.1.80 son la misma computadora portátil (con Ubuntu). El servidor es 172.16.1.5 y ejecuta Debian. Solía NetEm en el cliente conectado NIC para simular la pérdida de paquetes ...

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

EDITAR para respuestas de comentarios :

¿Puede explicar qué está sucediendo en el último escenario (1000BaseT, 5 transmisiones, pérdida del 2.0%)? Aunque hay pérdida de paquetes, el rendimiento total todavía está saturado a 937 Mbits / seg.

La mayoría de las implementaciones de TCP disminuyen su ventana de congestión cuando se detecta la pérdida de paquetes. Como estamos usando netem para forzar una pérdida de paquetes del 2% del cliente al servidor, algunos de los datos del cliente se descartan. El efecto neto de netem en este ejemplo es una velocidad de transmisión promedio de flujo único de 730Mbps. Agregar múltiples flujos significa que los flujos TCP individuales pueden trabajar juntos para saturar el enlace.

Mi objetivo es lograr el mayor rendimiento de TCP posible a través de WiFi. Según tengo entendido, debería aumentar el número de flujos para contrarrestar la disminución en el rendimiento causado por la pérdida de paquetes. ¿Es esto correcto?

si

Además, ¿en qué punto comenzarán demasiadas transmisiones a impactar negativamente el rendimiento? ¿Sería esto causado por una memoria limitada y / o potencia de procesamiento?

Realmente no puedo responder eso sin más experimentos, pero para los enlaces 1GE, nunca he tenido problemas para saturar un enlace con 5 flujos paralelos. Para darle una idea de cuán escalable es TCP, los servidores Linux pueden manejar más de 1500 sockets TCP concurrentes en las circunstancias correctas. Esta es otra discusión SO que es relevante para escalar sockets TCP concurrentes, pero en mi opinión, cualquier cosa por encima de 20 sockets paralelos sería excesivo si simplemente está tratando de saturar un enlace.

Debo tener un malentendido de que iperf usa el tamaño de ventana -w como máximo, ya que parece que estás diciendo que creció más allá de ese valor inicial de 21K

No lo usé iperf -w, así que creo que hay un malentendido. Dado que tiene tantas preguntas sobre el caso de wifi, incluyo un gráfico wirehark del rendimiento de TCP para el caso de flujo de TCP único wifi.

Rendimiento de flujo único TCP Wifi

Datos de prueba

También incluyo datos de prueba sin procesar en caso de que desee ver cómo medí estas cosas ...

802.11g, 1 flujo 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 flujos 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 transmisión, pérdida del 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 transmisiones, pérdida del 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 Streams, 2.0% de pérdida

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 transmisiones, pérdida 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:~$

Eliminar la simulación de pérdida de paquetes

mpenning@mpenning-ThinkPad-T61:~$ sudo tc qdisc del dev eth0 root
— Mike Pennington
fuente
¿Puede explicar qué está sucediendo en el último escenario (1000BaseT, 5 transmisiones, pérdida del 2.0%)? Aunque hay pérdida de paquetes, el rendimiento total todavía está saturado a 937 Mbits / seg. Mi objetivo es lograr el mayor rendimiento de TCP posible a través de WiFi. Según tengo entendido, debería aumentar el número de flujos para contrarrestar la disminución en el rendimiento causado por la pérdida de paquetes. ¿Es esto correcto? Además, ¿en qué punto comenzarán demasiadas transmisiones a afectar negativamente el rendimiento? ¿Sería esto causado por una memoria limitada y / o potencia de procesamiento?
— elin05
@ elin05: el uso de múltiples transmisiones distribuye la pérdida de paquetes en varias transmisiones, por lo que cuando se produce una pérdida de paquetes, solo una transmisión reducirá el tamaño de su ventana TCP, dejando a las otras transmisiones no afectadas.
— BatchyX
¿El BDP 802.11g (54 Mbps) no requiere un tamaño de ventana de 54 KB con un retraso de 8 ms (16 ms RTT / 2) para mantener la tubería llena de paquetes en vuelo? ¿Cuál es el tamaño de la ventana en el lado del servidor?
— generalnetworkerror
@generalnetworkerror, las ventanas TCP no son estáticas ... cambian según las necesidades de TCP ... durante esa captura, el tamaño máximo de ventana anunciado por Tsunami fue de 1177600 bytes; La ventana promedio de Tsunami fue de 1045083 bytes y el RTT promedio durante esa prueba de 60 segundos fue de 32.2 ms.
— Mike Pennington
@ MikePennington: Debo tener un malentendido de que iperf usa el tamaño de la ventana -w como máximo, ya que parece que estás diciendo que creció más allá de ese valor inicial de 21K.
— generalnetworkerror
2

Aquí está el cálculo para el rendimiento máximo de una sola transmisión tcp.

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

Entonces tiene un cuello de botella y la latencia juega un papel importante.

— James.Birmingham
fuente
0

Probablemente se deba a múltiples procesos versus un proceso. con iperf 2.0.9 se puede probar esto a través de -P 2 en el cliente. Esto bifurcará dos hilos en lugar de uno. La mayoría de las CPU modernas tienen múltiples núcleos, por lo que usar múltiples hilos podrá aprovecharlas.

— rjmcmahon
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.