Obteniendo información con Wireshark
Wireshark es sin duda una de las mejores herramientas gráficas para el análisis de tráfico de red. En mi caso particular, solo me limité a ciertas medidas analíticas de particular interés.
Llegó el momento de comprobar la estabilidad de ambos drivers en un escenario más real. Mediante Wireshark observaré si se ve afectado el comportamiento de TCP en la transmisión de datos (segmentos), y en que grado. Cabe recordar, que las pruebas descriptas en la primer parte del artículo, concluyeron en un resultado poco favorable del driver b43.
Análisis
Para este escenario simplemente capturé con Wireshark el tráfico de un par de descargas desde un sitio web en particular: https://mirrors.kernel.org/slackware/slackware-current/source/e/emacs/emacs-26.3.tar.xz. El paquete emacs-26.3.tar.xz tiene un tamaño aproximado de 42MB.
Capturadas las descargas intercambiando dichos drivers: (b43/wl), analicé los datos centrándome en algunos mensajes de TCP: retransmisiones, retransmisiones rápidas, ACK selectivos, ACK duplicados, etc.
Hay muchos parámetros a observar en Wireshark, no obstante, el número de retransmisiones me da una pauta del funcionamiento de la conexión entre: el emisor y receptor. Si bien es normal que tengamos retransmisiones a lo largo de una conexión, cuando estas se convierten en un patrón, significa que algo está fallando en la capa de transporte.
Los datos de TCP son obtenidos mediante las siguientes expresiones en el campo de filtrado de Wireshark:
- tcp.analysis.fast_retransmission = Retransmisión rápida
- tcp.analysis.retransmission = Retransmisión
- tcp.analysis.spurious_retransmission = Retransmisión espuria
- tcp.analysis.duplicate_ack = Reconocimiento duplicado
- tcp.analysis.out_of_order = Segmento Fuera de orden
La primer imagen corresponde al driver b43, y se desprenden los siguientes datos:
- Retransmisión rápida = 12
- Retransmisión 88 (0.2%)
- Retransmisión espuria 20
Total de retransmisiones 120 (0.2%)
- Segmento fuera de orden = 195 (0.4%)
- Reconocimiento duplicado = 3636 (6.8%)
Por el lado del driver wl:
- Retransmisión rápida = 20 (0.1%)
- Retransmisión = 0
- Retransmisión espuria = 0
Total de retransmisiones 20 (0.1%)
- Segmento fuera de orden = 60 (0.1%)
- Reconocimiento duplicado = 1819 (3.5%)
Reconocimiento duplicado y segmento fuera de orden
Los Reconocimientos duplicados y segmentos fuera de orden son, en parte, un desencadenante de retransmisiones. En ambos gráficos, el funcionamiento de TCP se ve más perjudicado con el driver b43, superando por el doble y más del triple sucesivamente, al driver wl en dichos apartados.
Yo esperaba que el driver wl estuviera exento de estos datos. De todas maneras, son muy inferiores a los que presenta el driver b43 y no limitan para nada el rendimiento de red.
Los reconocimientos duplicados (TCP Dup ACK) se presentan cuando se reconoce un segmento (mismo núm. de secuencia) consecutivamente. En este caso TCP activará el algoritmo de retransmisión rápida antes de que expire el temporizador. Las causas pueden deberse mayormente a segmentos fuera de orden. Versiones modernas de TCP generan ACK duplicados ante esta situación.
Posibles causas por la que TCP recibe segmentos fuera de orden (TCP Out-Of-Order) pueden deberse a:
- la red desordena los segmentos, algunos llegan antes que otros.
- se produce pérdida de segmento por congestión en la red, alterando el orden de secuencia esperada.
- latencia.
- baja en la red WLAN.
- problemas en el hardware (tarjeta de red).
- bajo rendimiento en transmisiones mediante Wireless.
Retransmisión, retransmisión rápida y retransmisión espuria
En el siguiente gráfico ya se aprecia con más claridad la disparidad que existe entre ambos drivers. Un dato curioso es en el apartado retransmisión rápida, el driver wl presenta casi el doble que b43. Sin embargo, las retransmisiones rápidas no radican un problema como tal, al contrario, forman parte de las mejoras en las funciones de TCP. Más adelante detallo porque se dan dichas retransmisiones.
En los demás campos (retransmisiones, retransmisiones espurias) sí suponen un problema, y son habituales en el driver b43. El driver wl está libre de retransmisiones, ni siquiera se dan en el arranque lento hasta alcanzar la ventana de congestión.
Retransmisión (TCP Retransmission): Cuando el emisor (cliente) envía al receptor (servidor) segmentos de datos con un número de secuencia (seq), espera una confirmación ACK de cada uno de esos segmentos en un orden establecido. Cuando llega la confirmación ACK al emisor significa que el segmento llegó a su destino y el emisor vuelve a mandar más segmentos. TCP inicia un temporizador RTO (Retransmission Time Out) por cada segmento enviado. Si no llega el ACK antes de que expire el tiempo RTO el emisor interpreta que el segmento se perdió y vuelve a retransmitir dicho segmento.
Retransmisión rápida (TCP Fast Retransmission): Como mencioné anteriormente, esta característica de TCP es una mejora y evita la retransmisión. Esta situación se da cuando se reciben reconocimientos duplicados, es decir, se reconoce (ACK) un mismo segmento en repetidas veces. TCP interpreta que el segmento se pudo haber perdido y lo retransmite antes de expire el temporizador. TCP retransmite el segmento al 3er. ACK duplicado. En Linux la llegada de ACKs duplicados es dinámica, es decir, no retransmite necesariamente al 3er. ACK duplicado.
Retransmisión espuria (TCP Spurious Retransmission): Sucede cuando TCP envía segmentos nuevamente, los cuales ya habían sido reconocidos por el receptor. TCP interpreta que los paquetes no llegaron al emisor, se perdieron en el camino. Un retardo en la llegada de ACKs por parte del receptor dispara el RTO del emisor.
Reconocimiento selectivo
La implementación de ACKs Selectivos también forman parte de las mejoras de TCP, ambos drivers son beneficiados con esta característica. El número de ACKs Selectivos en cada driver está dado por los ACKs Duplicados expuestos anteriormente.
En la parte derecha del gráfico se puede ver SLE (borde izquierdo) y SRE (borde derecho). Estos representan los segmentos que ya fueron reconocidos cuando TCP utiliza reconocimientos selectivos, para evitar la retransmisión de datos. Cuando se producen faltas de datos en el flujo, TCP identifica esos agujeros (SLE SRE). Esto sucede principalmente cuando los paquetes llegan fuera de orden. Básicamente nos está informando de que llegó el paquete, pero no obtuvo el anterior.
Queda demostrado como TCP, de acuerdo a los gráficos, es visiblemente más afectado por el driver b43, lo cual se deduce en un rendimiento inferior al obtenido con el driver wl. En el próximo artículo veremos la importancia que tienen las gráficas proporcionadas por Wireshark, y cuan esclarecedoras pueden resultar en casos como este.
Fuente:
https://www.wireshark.org/
https://es.wikipedia.org/wiki/Retransmisión_rápida
https://es.wikipedia.org/wiki/Protocolo_de_control_de_transmisión
http://www.tcpipguide.com/free/t_TCPCongestionHandlingandCongestionAvoidanceAlgorit-3.htm
¿Te resultó interesante? Compártelo ...
Consejo, consiguete un adaptador Atheros y adios a todos tus problemas. Son los mejores en cuanto a rendimiento y durabilidad y su soporte de Drivers es excepcional con ath9k. Con ath9k puedes configurar muchas cosas, para no decirte que casi todo. Por gusto no es la opción preferida por Ubiquiti, Mikrotik, … para sus equipos.Si no puedes conseguir un adaptador Atheros, prueba con adaptadores Ralink que tambien son buenos aunque menos configurables, si tampoco te encuentras uno Ralink consigue uno Realtek que tambien proporcionan buen rendimiento aunque deberias tener ojo con la temperaturaya que algunos modelos se quedan ciegos cuando se sobrecalientan y hasta que no se enfrien no trabajan bien, asi como sus driver es en windows q son un poco problematicos a diferencia de linux jjj. Broadcom no te lo recomiendo para nada, son malos a nivel de rendimiento, pocas opciones configurables se sobrecalientan mucho y se joden de nada, te lo digo por experiencia propia se me jodio una Netgear dual band con chipset Broadcom a las horas de estar conectada a la pc, y unos cuantos LynkSys WRT 45G que los he tenido que coger de switch porque se les que el chipset del wifi, sin contra los problemas de drivers que has experimentado y que he visto varios post en el blog referente a problemas con los driver de Broadcom.
Broadcom siempre a sido una gran espina para Linux, sin embargo con el tiempo ha ido mejorando el soporte a través del driver b43. Eso no descarta que sea uno de los más problemáticos como bien dices. De comprar un nuevo hardware, lo primero sería cerciorarme que la tarjeta de red no sea Broadcom.
El rendimiento a sido aceptable desde Debian 6 (2.6.32) hasta el kernel 4.9.0 (Debian 9). En el próximo artículo se verá más claro este apartado.
En cuanto a los adaptadores no está nada mal Atheros, y los precios son razonables. Si no tuviera solución (por el momento uso el driver wl), o necesitara funcionalidades extras, lo ideal podría ser reemplazar la tarjeta de red interna por una Atheros.
Muchas gracias por tus recomendaciones, es bueno saber de otras experiencias y alternativas viables.
Saludos.