Nota: Este es el primero de una sucesión de artículos, donde dejo plasmado los diferentes métodos y herramientas que utilicé para comparar y analizar los drivers citados aquí.
Este tema viene a colación de otro artículo, donde detallé los inconvenientes que estaba teniendo con el driver b43. Es por ello que decidí comenzar una serie de pruebas comparativas intercambiando ambos drivers: el wl (broadcom-sta) y el cuestionado b43. El propósito, simplemente determinar —en lo posible— que driver ofrece un mejor rendimiento de red.
Especificaciones:
- Distribución: Debian 10 (Buster).
- Kernel: 4.19.0-6-amd64.
- Network controller: Broadcom Limited BCM4312 802.11b/g LP-PHY (rev 01).
- Driver: b43 (default).
- Driver: wl (opcional).
Comencé con algunas pruebas muy sencillas para poder determinar si se trata de un problema del driver en sí, o simplemente es un problema de configuración. La primera prueba la realicé con el comando ping para comprobar la latencia de red. El ancho de banda es de 6 Mbps (750 KB/s).
Recolección de datos con: ping
El comando ping, como herramienta de diagnóstico aporta datos concretos muy fáciles de interpretar. Además, apoyado en la representación gráfica, se obtiene un panorama más amplio desde el punto de vista analítico. En definitiva, ayudan a comprender mejor el comportamiento de dichos datos. El software estadístico a utilizar fue R.
Las direcciones de red a testear fueron: google.com y debian.org. Esta última, particularmente necesaria su comprobación debido al uso de sus repositorios. La recolección de datos la obtuve redirigiendo la salida del comando ping para conformar una tabla, posteriormente será leída por el entorno R.
Esta sería una salida normal —para google en este caso—: ping -nc50 google.com
PING google.com (172.217.28.174) 56(84) bytes of data. 64 bytes from (172.217.28.174): icmp_seq=1 ttl=53 time=28.5 ms 64 bytes from (172.217.28.174): icmp_seq=2 ttl=53 time=173 ms 64 bytes from (172.217.28.174): icmp_seq=3 ttl=53 time=27.5 ms 64 bytes from (172.217.28.174): icmp_seq=4 ttl=53 time=226 ms 64 bytes from (172.217.28.174): icmp_seq=5 ttl=53 time=44.8 ms 64 bytes from (172.217.28.174): icmp_seq=7 ttl=53 time=189 ms 64 bytes from (172.217.28.174): icmp_seq=8 ttl=53 time=29.2 ms ... ... 64 bytes from (172.217.28.174): icmp_seq=48 ttl=53 time=31.6 ms 64 bytes from (172.217.28.174): icmp_seq=49 ttl=53 time=28.0 ms 64 bytes from (172.217.28.174): icmp_seq=50 ttl=53 time=29.10 ms --- google.com ping statistics --- 50 packets transmitted, 49 received, 2% packet loss, time 130ms rtt min/avg/max/mdev = 27.546/75.060/225.644/69.379 ms
El siguiente comando obtiene los datos para el driver b43 redirigiendo al archivo b43-ping-google.txt:
ping -nc50 google.com > b43-ping-google.txt
a continuación hice un filtrado utilizando los comandos: cat, awk y tr. La salida se redirige a b43-tabla-google.txt, el cual, será mi fichero final con la tabla de datos:
cat b43-ping-google.txt |awk -F'=' '{print $2 $4}' | tr -d 'ms,ttl' > b43-tabla-google.txt
Un método más directo con menos información para analizar. Aquí se obtiene solamente la tabla:
ping -nc50 google.com |awk -F'=' '{print $2 $4}' | tr -d 'ms,ttl' > b43-tabla-google.txt
. Los encabezados son opcionales, y la última linea perteneciente a min/avg/max/mdev fue eliminada en el análisis de R.
Finalmente los archivos con los datos quedarían conformados con la siguiente estructura:
Archivo: b43-tabla-google.txt
count ms 1 28.5 2 173 3 27.5 4 226 5 44.8 7 189 8 29.2 ... ... ... 48 31.6 49 28.0 50 29.10
Completadas las tablas de datos: b43-tabla-google.txt y b43-tabla-debian.txt procedí a la instalación del driver broadcom-sta.
sudo apt install broadcom-sta-dkms
Finalizada la obtención de los datos correspondientes al driver wl: wl-tabla-google.txt y wl-tabla-debian.txt, el resto de la operatoria queda en manos de R. Sin embargo, antes de pasar a los gráficos, se pueden analizar algunos datos curiosos que ya muestran un patrón:
ping google.com
b43
--- google.com ping statistics --- 50 packets transmitted, 49 received, 2% packet loss, time 130ms rtt min/avg/max/mdev = 27.546/75.060/225.644/69.379 ms
wl
--- google.com ping statistics --- 50 packets transmitted, 50 received, 0% packet loss, time 127ms rtt min/avg/max/mdev = 27.682/28.951/32.338/0.744 ms
ping debian.org
b43
--- debian.org ping statistics --- 50 packets transmitted, 41 received, 18% packet loss, time 265ms rtt min/avg/max/mdev = 254.263/305.603/454.773/58.532 ms
wl
--- debian.org ping statistics --- 50 packets transmitted, 50 received, 0% packet loss, time 62ms rtt min/avg/max/mdev = 202.152/203.717/208.358/1.350 ms
En la primera comparación (google.com ping) no parece haber diferencias entre ambos, solamente 1 paquete perdido (b43), en cambio, sí se observa cierta diferencia en la desviación media: un valor de 69.379 ms (b43) contra 0.744 ms (wl) es altamente perceptible y no necesariamente bueno.
De acuerdo a Wikipedia:
Desviación media:
En estadística la desviación absoluta promedio o, sencillamente desviación media o promedio de un conjunto de datos es la media de las desviaciones absolutas y es un resumen de la dispersión estadística.
Dispersión estadística:
Las medidas de dispersión muestran la variabilidad de una distribución, indicándolo por medio de un número, si las diferentes puntuaciones de una variable están muy alejadas de la media. Cuanto mayor sea ese valor, mayor será la variabilidad, cuanto menor sea, más homogénea será a la media. Así se sabe si todos los casos son parecidos o varían mucho entre ellos.
En el caso del driver b43 ese valor refleja cierta irregularidad en comparación con el driver wl cuyo valor es apenas 0.744 ms. Esta homogeneidad en los valores del driver wl se traduce en un comportamiento más que estable.
En la siguiente comparación (debian.org) dicha medida sigue siendo bastante significativa: 58.532 ms (b43) vs 1.350 ms (wl), y en este caso, los valores que pueden preocupar son más bien la pérdida de paquetes: 18% packet loss (9/50), además de un tiempo de respuesta elevado de 265 ms (b43) vs. 62 ms (wl).
Gráficos
En la representación gráfica puede verse reflejado muy claramente el comportamiento de cada driver. La siguiente secuencia de comandos aluden a la consola de Rcommander.
Archivo RScript: Rcommander.R
b43_g<-read.table("b43-tabla-google.txt", header=T) b43_d<-read.table("b43-tabla-debian.txt", header=T) wl_g<-read.table("wl-tabla-google.txt", header=T) wl_d<-read.table("wl-tabla-debian.txt", header=T) par(mfrow=c(2,2)) plot(ms~count, data=wl_g, col='blue', main='wl ping google.com', type='s', lwd=2, ylim=c(0,250)) plot(ms~count, data=b43_g, col='red', main='b43 ping google.com', type='s', lwd=2, ylim=c(0,250)) plot(ms~count, data=wl_d, col='blue', main='wl ping debian.org', type='s', lwd=2, ylim=c(0,500)) plot(ms~count, data=b43_d, col='red', main='b43 ping debian.org', type='s', lwd=2, ylim=c(0,500))
En dicho script se detallan uno a uno los pasos que utilicé para la obtención de los siguientes gráficos:
Creo que esta comparación lo dice todo, mientras que en los gráficos de la izquierda (wl) existe una linea consistente a lo largo de todo el proceso (ping), por su parte, los gráficos correspondientes al driver (b43) muestran un patrón —no deseado— de principio a fin. Los picos demasiados ascendentes son recurrentes, y podrían deberse en parte a retransmisiones: se supone pérdida de paquetes, en consecuencia, se producen demoras en el tráfico de red.
Si bien estamos hablando de milisegundos, no hay que engañarse, en conexiones largas esos milisegundos cuentan. Y en muchos casos los sitios web demoran lo suficiente, tanto, como para afectar la experiencia de usuario. Tal vez, en un ancho de banda más grande el problema es imperceptible. No obstante, el punto aquí es comprobar el desempeño del dispositivo de red ofrecido por el driver b43, y contrastarlo con el wl.
En la siguiente gráfica los mismos datos son representados en un modelo de histograma:
Una vez más se puede observar muy claramente un mejor comportamiento del driver wl en comparación con el b43. En este modelo (histograma), además de percibir los picos elevados mencionados anteriormente, también se revelan los espacios en blanco (b43). Dichos espacios indican los paquetes perdidos: 1 (49/50 2%) paquete en el caso de ping google.com y 9 (41/50 18%) correspondientes a debian.org.
Es conveniente aclarar que en los gráficos wl, la linea casi plana, es debido al emparejamiento de la escala, para que la comparación entre ambos gráficos sea objetiva. Sin embargo, en un gráfico individual y a escala más pequeña, se reflejan oscilaciones regulares dentro de un rango muy pequeño de la misma:
estas oscilaciones también son aplicables al driver b43 en escasos sectores en la parte baja de la escala. En ambos casos se supone que este tipo de variaciones son totalmente normales.
Con simples pruebas ya tengo una idea bastante clara de como responde cada driver. Sin embargo, es prematuro afirmar que puede estar causando un rendimiento inferior con el driver b43. En el segundo artículo utilizaré una herramienta más específica para ver si se replican los mismos patrones en ambos drivers.
Fuente:
https://es.wikipedia.org/wiki/Ping
https://es.wikipedia.org/wiki/Desviación_media
https://es.wikipedia.org/wiki/Medidas_de_dispersión
Otro excelentísimo artículo colega
Muchas gracias @Maikel !!
Saludos.