Blog de AlterMundi

Rendimiento en redes mesh con múltiples saltos encadenados con routers multi-banda de radio-dual

Los routers utilizados para esta prueba son TP-Link WDR3600 utilizando AlterMesh basado en OpenWRT r33815. Este enrutador es un modelo multibanda que funciona simultáneamente en 2.4Ghz y 5Ghz. Es MIMO 2×2. El protocolo de enrutamiento utilizado es batman advanced 2012.4.0.

La red de prueba consiste en cuatro routers de este tipo utilizando sus antenas omnidireccionales de fábrica (haga clic en la imagen para ampliar y ver una foto de cada nodo).

Están situados a una distancia aproximada de 50 metros uno del otro en una línea en zigzag. En este entorno semi-rural todo el ruido wifi 2.4Ghz proviene de nuestra red comunitaria y la banda 5Ghz está completamente limpia. Una exploración típica en esta área en particular sólo muestra dos de nuestros nodos con una intensidad de señal de -78 / -80.

La vegetación sirve a propósito como una barrera parcial entre los nodos. La tabla de originators de cada enrutador muestra que se están viendo como se esperaba; es decir: cada router elige a sus vecinos más cercanos como salto siguiente en cada dirección y están vinculados en 2.4Ghz y 5Ghz simultáneamente. La tasa de multidifusión se establece en 54000 y la potencia tx se establece en 9 en cada nodo. En esta configuración en particular, esos valores dieron los resultados más limpios manteniendo un buen rendimiento general.

A continuación, algunas conclusiones. La salida Iperf se ha truncado para acortar el texto resultante de tantas pruebas. Cada prueba se llevó a cabo una varias veces y los resultados publicados son aquellos que consideramos más representativos.

ping a través de la red de prueba

El test de ping inicial esta corriendo desde una computadora con conexión cableada con el node_a.

$ sudo ping node_d -i 0.1 -c 100
--- node_d ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 9966ms
rtt min/avg/max/mdev = 2.762/6.951/62.385/7.231 ms

No existe pérdida de paquetes en el camino entre node_d y el retraso es bajo.

Tabla de originators desde cada nodo

Como expliqué en la introducción, las tablas muestran que el testeo de los nodos está ruteando el tráfico como esperamos.
Estas tablas son dinámicas por naturaleza. Es interesante notar que cuando la red no tiene tráfico casi todos los nodos eligen los enlaces 5Ghz, pero cuando el tráfico comienza a moverse empezarán a alternar entre 2,4 y 5.

root@node_a:~# batctl o
[B.A.T.M.A.N. adv 2012.4.0, MainIF/MAC: wlan0-2/66:70:02:ed:f9:81 (bat0)]
Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ...
node_d_2.4Ghz 0.340s (198) node_b_5Ghz [ wlan1]: node_b_5Ghz (198) node_b_2.4Ghz (182)
node_b_5Ghz 0.420s (255) node_b_5Ghz [ wlan1]: node_b_5Ghz (255)
node_b_2.4Ghz 0.530s (255) node_b_5Ghz [ wlan1]: node_b_5Ghz (255) node_b_2.4Ghz (234)
node_c_5Ghz 0.440s (225) node_b_5Ghz [ wlan1]: node_b_5Ghz (225)
node_c_2.4Ghz 1.820s (222) node_b_5Ghz [ wlan1]: node_b_5Ghz (222) node_b_2.4Ghz (209)
root@node_b:~# batctl o
[B.A.T.M.A.N. adv 2012.4.0, MainIF/MAC: wlan0-2/66:70:02:ee:02:e9 (bat0)]
Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ...
node_d_2.4Ghz 0.520s (221) node_c_5Ghz [ wlan1]: node_c_5Ghz (221) node_c_2.4Ghz (206)
node_a_2.4Ghz 0.800s (251) node_a_5Ghz [ wlan1]: node_a_5Ghz (251) node_a_2.4Ghz (235)
node_d_5Ghz 0.740s (225) node_c_5Ghz [ wlan1]: node_c_5Ghz (225)
node_c_5Ghz 0.630s (255) node_c_5Ghz [ wlan1]: node_c_5Ghz (255)
node_a_5Ghz 0.920s (251) node_a_5Ghz [ wlan1]: node_a_5Ghz (251)
node_c_2.4Ghz 0.950s (255) node_c_5Ghz [ wlan1]: node_c_5Ghz (255) node_c_2.4Ghz (242)
root@node_c:~# batctl o
[B.A.T.M.A.N. adv 2012.4.0, MainIF/MAC: wlan0-2/66:70:02:ee:01:b7 (bat0)]
Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ...
node_d_2.4Ghz 0.790s (255) node_d_2.4Ghz [ wlan0-2]: node_d_5Ghz (251) node_d_2.4Ghz (255)
node_a_2.4Ghz 0.750s (217) node_b_5Ghz [ wlan1]: node_b_5Ghz (217) node_b_2.4Ghz (213)
node_b_5Ghz 0.600s (251) node_b_5Ghz [ wlan1]: node_b_5Ghz (251)
node_d_5Ghz 0.900s (255) node_d_5Ghz [ wlan1]: node_d_5Ghz (255)
node_b_2.4Ghz 0.630s (251) node_b_5Ghz [ wlan1]: node_b_5Ghz (251) node_b_2.4Ghz (242)
node_a_5Ghz 0.820s (221) node_b_5Ghz [ wlan1]: node_b_5Ghz (221)
root@node_d:~# batctl o 
[B.A.T.M.A.N. adv 2012.4.0, MainIF/MAC: wlan0-2/66:70:02:ed:f8:dd (bat0)]
  Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ...
node_a_2.4Ghz 0.170s (192) node_c_5Ghz [ wlan1]: node_c_5Ghz (192) node_c_2.4Ghz (169)
node_b_5Ghz 0.060s (221) node_c_5Ghz [ wlan1]: node_c_5Ghz (221)
node_b_2.4Ghz 0.160s (221) node_c_5Ghz [ wlan1]: node_c_5Ghz (221) node_c_2.4Ghz (192)
node_c_5Ghz    0.330s   (255)       node_c_5Ghz [     wlan1]:       node_c_5Ghz (255)
node_c_2.4Ghz    0.670s   (255)       node_c_5Ghz [     wlan1]:       node_c_5Ghz (255)     node_c_2.4Ghz (221)

iperf en un enlace entre el nodo_a y el nodo_d

root@node_a:~# iperf -c node_b
[  3]  0.0-10.0 sec  75.5 MBytes  63.1 Mbits/sec
root@node_b:~# iperf -c node_c
[  3]  0.0-10.0 sec  69.5 MBytes  58.3 Mbits/sec
root@node_c:~# iperf -c node_d
[  3]  0.0-10.0 sec  77.0 MBytes  64.5 Mbits/sec

iperf en un enlace entre el nodo_a y el nodo_c, y entre el nodo_a y el nodo_d

root@node_a:~# iperf -c node_c
[  3]  0.0-10.1 sec  46.5 MBytes  38.7 Mbits/sec
root@node_a:~# iperf -c node_d
[  3]  0.0-10.1 sec  39.0 MBytes  32.4 Mbits/sec

iperf independiente en enlaces de 2.4 y 5 Ghz entre nodos

Cada nodo de esta red está vinculado a sus vecinos a través de 2.4Ghz y 5Ghz, por lo que en esta prueba nos proponemos averiguar cuál es el rendimiento real de cada enlace a lo largo de nuestra ruta probada (de node_a a node_d).

wlan0-2 is 2.4Ghz and wlan1 is 5Ghz in every node. We force the traffic through each interface using local IPv6 addresses.

root@node_a:~# export node_b_24_v6=fe80::6470:2ff:feee:2e9
root@node_a:~# iperf -V -c $node_b_24_v6%wlan0-2
[  3]  0.0-10.0 sec  61.9 MBytes  51.8 Mbits/sec
root@node_a:~# export node_b_5_v6=fe80::6670:2ff:feee:2e8
root@node_a:~# iperf -V -c $node_b_5_v6%wlan1
[  3]  0.0-10.0 sec  70.8 MBytes  59.2 Mbits/sec
root@node_b:~# export node_c_24_v6=fe80::6470:2ff:feee:1b7
root@node_b:~# iperf -V -c $node_c_24_v6%wlan0-2
[  3]  0.0-10.0 sec  49.4 MBytes  41.3 Mbits/sec
root@node_b:~# export node_c_5_v6=fe80::6670:2ff:feee:1b6
root@node_b:~# iperf -V -c $node_c_5_v6%wlan1
[  3]  0.0-10.0 sec  61.8 MBytes  51.7 Mbits/sec
root@node_c:~# export node_d_24_v6=fe80::6470:2ff:feed:f8dd
root@node_c:~# iperf -V -c $node_d_24_v6%wlan0-2
[  3]  0.0-10.0 sec  56.1 MBytes  47.0 Mbits/sec
root@node_c:~# export node_d_5_v6=fe80::6670:2ff:feed:f8dc
root@node_c:~# iperf -V -c $node_d_5_v6%wlan1
[  3]  0.0-10.0 sec  72.3 MBytes  60.5 Mbits/sec

Conclusiones:

El enlace más lento en el camino es el enlace 2.4Ghz entre node_b y node_c a 41.3Mbit/s y el siguiente más lento es el enlace 2.4Ghz contiguo desde node_c a node_d a 47Mbit/s. Así que incluso si nuestro protocolo de enrutamiento está alternando correctamente entre las rutas disponibles, un iperf de extremo a extremo tendrá siempre un cuello de botella de 47 o 41.3Mbit / s. Como resultado, la ruta de nodo_a a nodo_c a una tasa de 32,4 Mbit / s está sufriendo aproximadamente 25% de degradación del rendimiento. También vale la pena mencionar que la comparación de los resultados de ejecutar iperf de node_a a node_c con la ejecución de nodo_a a node_d, por lo tanto, agregando sólo un salto en la ruta, hay una caída de 6Mbit / s en el rendimiento, que es coherente con la degradación observada para el ruta completa.

498/5000
En una única malla de radio, la degradación teórica es de 50 % por salto, por lo que en nuestra configuración, el 59.2Mbit / s inicial (node_a_5Ghz – node_b_5Ghz) se habría degradado a aproximadamente 15Mbit / s. En 2.4Ghz los 51.8Mbit / s iniciales se habrían degradado a 13Mbit / s. Comparando estos valores teóricos optimistas de una sola radio con el experimento multi-radio del mundo real realizado aquí, podemos asegurar que las redes de malla multi-radio / multi-band tienen un enorme potencial, incluso en los routers de bajo precio.

Las pruebas futuras podrían tratar de establecer enlaces óptimos tanto en 2.4Ghz como en 5Ghz entre nodos vecinos para probar el límite de rendimiento final real de tal red. También sería interesante establecer si la degradación observada de ~ 6Mbit /s por salto observada en este experimento es un límite real de tales redes o no.

Por ahora, esta serie de pruebas es suficiente para demostrar que las redes mesh multi-radio no sufren una reducción del ancho de banda a la mitad por degradación en saltos que sufren los enlaces de radio única.

H3. Coda: udp iperf de node_a a node_d

Sabemos que el enlace más débil es de 41Mbit / s, por lo que enviamos un iperf de 40Mbit / s desde node_a a node_d, y el resultado informado por el servidor en node_d es 38.5Mbit / s.

root@node_a:/tmp# iperf -c node_d -b 40M -u
WARNING: option -b implies udp testing
------------------------------------------------------------
Client connecting to node_d, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:  160 KByte (default)
------------------------------------------------------------
[  3] local 10.5.0.24 port 57273 connected with 10.5.0.27 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  47.5 MBytes  39.9 Mbits/sec
[  3] Sent 33912 datagrams
[  3] Server Report:
[  3]  0.0-10.0 sec  46.0 MBytes  38.5 Mbits/sec   0.437 ms 1104/33913 (3.3%)
Last modification date: Jan. 22, 2013, 10:42 p.m.
There are 4 comments
  • Jan. 16, 2013, 12:42 a.m. - By: T_X - (permalink)

    Hi guys!

    Thanks a lot for this very valuable information - I'm pretty positiv that "open sourcing" such tests with free software is a very important thing for developing and improving our mesh networks. Something which certainly should be done more often, especially as the still quite limited number of free software developers very often only have quite limited time to do these time consuming tasks themselves.

    I really like that you pretty much have all the important points describing your setup, that you have made tests with batman-adv, the setup you wanna use in production, but also compared them with individual link performance tests. That really helps getting a picture of what part might be a performance bottleneck or not.

    Just a few minor things which would be great having if you were going to do and publish some more tests in the future:
    * You're saying the area is semi-rural which is a quite subjective term. Maybe include an 'iwlist' output, maybe an air-usage screenshot with H.O.R.S.T., a vnstat output from a monitor mode interface and/or wireshark graph on monitor mode interface?
    * Maybe include an 'iw dev wlan-adhoc station dump' output to show that mimo is working correctly (I'm actually not quite sure, does the wdr3600 really provide and use MIMO on both 2.4 and 5GHz?).
    * What were the antennas used?
    * 10s test intervals seems way too low for wifi from my experiences. I usually was using 3 runs at 3min. per trial as some bugs only show up in spikes from time to time etc. Such longer intervals will also make it possible to draw graphs to see how stable the wifi and how representative or random the final averages are. gnuplot (or simply open sourcing the raw logs to let someone else draw nice graphs) would be great
    * Did you perform the independent link tests all at different times? or all at the same time? I guess the former, though both seems wrong. The first does not take interference of the own stream / shared medium into account nor any possible hidden node problems.

    I also have to disagree a little with the conclusion. When looking at the individual results it looks like 47mbit/s would be the bootleneck via c-2.4-d (while using a-2.4-b-5-c-2.4-d). Ideally all 2^4 possible paths (via using iperf on the wifi link itself, but several instances of iperf simultaneously) would need to be tested to be sure of over longer times would be needed (so scripting some automated tests would be needed for such several hours long tests then).

    Thanks again for sharing these very insightful tests and their results and all the time you invested for that!

    Cheers, T_X

    Reply
  • Jan. 16, 2013, 12:46 a.m. - By: T_X - (permalink)

    PS: I'll also need to show this around at our local, regular mesh community gatherings in our city as a great example of how a well made, detailed tests could look like. Maybe it'll spark some interest in creating and sharing something similar here, too, let's see :).

    Reply
  • Jan. 22, 2013, 9:27 p.m. - By: Nicolás Echániz - (permalink)

    T_X, thanks a lot four your detailed comment. We plan to extend this experiment soon and post the results so your ideas and tips will come very handy. There are some missing details on the test setup that I plan to add when I get the time... but you know what they say: "release early, release often" :) Regarding the conclusions, I guessed the bottleck would be node_b-2.4-node_c, which shows the lowest throughput at 41.3Mbit/s. Scripting more exhaustive tests is exactly what we plan to do; we'll share that when it's done also. Let us know through the batman-adv mailing list if you publish test results from your mesh! cheers

    Reply
  • Jan. 20, 2014, 12:13 p.m. - By: SnidendArrownap - (permalink)

    <a href="http://freecialiscialissaleyce.com/#ptdq">cialis dosage</a> at incredibly low prices when you purchase from discount,How long does <a href="http://freecialiscialissalestrh.com/#rjnw">order cialis online</a> is easy.,A reliable site allows you to speak to a pharmacist when buying <a href="http://cialisukcialissoftarry.com/#kqgd">cialis cost</a>

    Reply
captcha
I want to be notified by email when there is a new comment.