Drivers Linux: b43 vs. wl (1/3)

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.

Debian instala y compila automáticamente el driver sin necesidad de intervenir manualmente. También deshabilita y pone en lista negra los drivers que puedan producir conflictos: b43, ssb, bcma, etc.
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://www.r-project.org/

https://www.rcommander.com/

https://es.wikipedia.org/wiki/Ping

https://es.wikipedia.org/wiki/Desviación_media

https://es.wikipedia.org/wiki/Medidas_de_dispersión

¿Te resultó interesante? Compártelo ...



Percaff_TI99

Publicado por Percaff_TI99

http://gutl.jovenclub.cu/ » Forma parte de GUTL desde el 10 agosto, 2013. Amante de la ciencia y tecnología en general. Usuario de GNU/Linux desde hace varios años.

Este artículo tiene 2 comentarios

Los comentarios están cerrados.