Repository : ssh://git@open-mesh.org/doc

On branch : master

commit e05d49d50c0a15197008b7d6d24e533cb21a0602 Author: Sven Eckelmann sven@narfation.org Date: Thu Jul 13 20:46:24 2017 +0200

doc: Remove testlog only pages

Signed-off-by: Sven Eckelmann sven@narfation.org

e05d49d50c0a15197008b7d6d24e533cb21a0602 batman-adv/BATMAN_V_Tests.rst | 295 -------------------------------- batman-adv/Bandwidth_meter_tests.rst | 198 --------------------- batman-adv/Kmalloc-kmem-cache-tests.rst | 273 ----------------------------- batman-adv/index.rst | 3 - batman-adv/kmalloc-kmem-cache-setup.dia | Bin 2982 -> 0 bytes batman-adv/kmalloc-kmem-cache-setup.png | Bin 22315 -> 0 bytes batman-adv/kmalloc_vs_kmem-cache.png | Bin 6731 -> 0 bytes 7 files changed, 769 deletions(-)

diff --git a/batman-adv/BATMAN_V_Tests.rst b/batman-adv/BATMAN_V_Tests.rst deleted file mode 100644 index 858b6fa..0000000 --- a/batman-adv/BATMAN_V_Tests.rst +++ /dev/null @@ -1,295 +0,0 @@ -BATMAN V Tests -============== - -The following tests have been performed on -[[open-mesh:Emulation|OpenWRT with emulation setup]] to test -convergence times. - -Configuration: -============== - -Each scenario has been tested with a corresponding setup script (see -attached). Links have been killed using the commands as stated in each -test report. - -OpenWRT commands to set up the nodes after bootup: - -:: - - NUM=$(ifconfig eth0| grep HWaddr | sed 's/:01[\n\ ]*$//' | sed 's/.*://'| sed 's/[\n\ ].*//') - batctl if del eth0 - batctl if del eth1 - ifconfig br-lan down - brctl delbr br-lan - echo BATMAN_IV > /sys/module/batman_adv/parameters/routing_algo - ifconfig eth0 up - ifconfig eth1 up - batctl if add eth0 - batctl if add eth1 - - ifconfig bat0 hw ether FE:F1:00:00:${NUM}:01 - ifconfig bat0 inet 192.168.0.$(printf %d 0x${NUM}) up - -Originator interval: - -- B.A.T.M.A.N. IV: 1 second (default) -- B.A.T.M.A.N. V: 1 second (default) - -Tests -===== - -Host restart ------------- - -Scenario: 2 nodes talking to each other (any of the scripts will work) - -On one node, run: - -:: - - batctl if del eth0 ; batctl if del eth1 - sleep 1 - batctl if add eth0 ; batctl if add eth1 - -Results: - -| B.A.T.M.A.N. IV: OGM table recovers within 30 seconds -| B.A.T.M.A.N. V: OGM table recovers within 30 seconds - -Both recovery times are due to the protection window - -Convergence times ------------------ - -The triangle -~~~~~~~~~~~~ - -Scenario: - -|image0| - -| Pinging from node 1 and 2 -| killing connection between 1 and 2 by kill $(cat killme.pid) - -Results: - -| B.A.T.M.A.N. V: 6 seconds to recover -| 64 bytes from 192.168.0.2: seq=10 ttl=64 time=0.423 ms -| 64 bytes from 192.168.0.2: seq=11 ttl=64 time=1.055 ms -| 64 bytes from 192.168.0.2: seq=16 ttl=64 time=2.174 ms - -| B.A.T.M.A.N. IV: 6 seconds to recover -| 64 bytes from 192.168.0.2: seq=8 ttl=64 time=0.870 ms -| 64 bytes from 192.168.0.2: seq=9 ttl=64 time=1.430 ms -| 64 bytes from 192.168.0.2: seq=15 ttl=64 time=2.391 ms -| 64 bytes from 192.168.0.2: seq=16 ttl=64 time=2.190 ms - -The circle, I -~~~~~~~~~~~~~ - -|image1| - -| ping from B to A (ping 192.168.0.11) -| batctl o | grep fe:f0:00:00:0b:01 --> verify direction (flaps often - in BATMAN IV) -| kill $(cat killmeTOP.pid) -| kill $(cat killmeBOTTOM.pid) - -| B.A.T.M.A.N. V: 6 seconds to recover -| 64 bytes from 192.168.0.11: icmp_req=7 ttl=64 time=2.45 ms -| 64 bytes from 192.168.0.11: icmp_req=8 ttl=64 time=1.88 ms -| 64 bytes from 192.168.0.11: icmp_req=14 ttl=64 time=3.33 ms -| 64 bytes from 192.168.0.11: icmp_req=15 ttl=64 time=4.41 ms - -| B.A.T.M.A.N. IV: 6 seconds to recover -| 64 bytes from 192.168.0.11: icmp_req=1 ttl=64 time=4.13 ms -| 64 bytes from 192.168.0.11: icmp_req=2 ttl=64 time=3.47 ms -| 64 bytes from 192.168.0.11: icmp_req=8 ttl=64 time=4.21 ms -| 64 bytes from 192.168.0.11: icmp_req=9 ttl=64 time=283 ms - -The circle, II -~~~~~~~~~~~~~~ - -|image2| - -| ping from N12 to A, since this was taking the top path -| kill $(cat killmeBOTTOM.pid) - -| B.A.T.M.A.N. V: 5 seconds to recover -| 64 bytes from 192.168.0.1: icmp_req=4 ttl=64 time=4.43 ms -| 64 bytes from 192.168.0.1: icmp_req=5 ttl=64 time=4.61 ms -| 64 bytes from 192.168.0.1: icmp_req=10 ttl=64 time=3.66 ms -| 64 bytes from 192.168.0.1: icmp_req=11 ttl=64 time=3.53 ms - -| B.A.T.M.A.N. IV: 6 seconds to recover -| 64 bytes from 192.168.0.1: icmp_req=20 ttl=64 time=3.21 ms -| 64 bytes from 192.168.0.1: icmp_req=21 ttl=64 time=2.80 ms -| 64 bytes from 192.168.0.1: icmp_req=22 ttl=64 time=3.95 ms -| 64 bytes from 192.168.0.1: icmp_req=28 ttl=64 time=2.83 ms - -The bottle -~~~~~~~~~~ - -|image3| - -| ping from B to A -| kill top or bottom, depending on which path is active -| kill $(cat killmeTOP.pid) -| kill $(cat killmeBOTTOM.pid) - -| B.A.T.M.A.N. V: 6 seconds to recover -| 64 bytes from 192.168.0.9: icmp_req=3 ttl=64 time=4.28 ms -| 64 bytes from 192.168.0.9: icmp_req=9 ttl=64 time=3.71 ms -| 64 bytes from 192.168.0.9: icmp_req=10 ttl=64 time=4.42 ms -| 64 bytes from 192.168.0.9: icmp_req=11 ttl=64 time=4.17 ms - -| B.A.T.M.A.N. IV: 6 seconds to recover -| 64 bytes from 192.168.0.9: icmp_req=2 ttl=64 time=4.18 ms -| 64 bytes from 192.168.0.9: icmp_req=3 ttl=64 time=3.45 ms -| 64 bytes from 192.168.0.9: icmp_req=9 ttl=64 time=4.00 ms -| 64 bytes from 192.168.0.9: icmp_req=10 ttl=64 time=3.96 ms - -Mobility --------- - -While A is moving through the mesh the route between A and B shall -recover as fast as possible. - -New neighbor -~~~~~~~~~~~~ - -|image4| - -| from A (7): ping 192.168.0.3 (B in the graph) -| kill $(cat killmeMOBILE.pid) ; \ -| wirefilter --daemon -v num0_7.ctl:num0_2.ctl --pidfile - killmeMOBILE.pid -| kill $(cat killmeMOBILE.pid) ; \ -| wirefilter --daemon -v num0_7.ctl:num0_1.ctl --pidfile - killmeMOBILE.pid - -| B.A.T.M.A.N. V: -| 1->2: 5 seconds -| 64 bytes from 192.168.0.3: icmp_req=11 ttl=64 time=1.53 ms -| 64 bytes from 192.168.0.3: icmp_req=12 ttl=64 time=2.13 ms -| 64 bytes from 192.168.0.3: icmp_req=17 ttl=64 time=1.23 ms -| 64 bytes from 192.168.0.3: icmp_req=18 ttl=64 time=1.54 ms -| 2->1: 5 seconds -| 64 bytes from 192.168.0.3: icmp_req=5 ttl=64 time=1.08 ms -| 64 bytes from 192.168.0.3: icmp_req=6 ttl=64 time=2.26 ms -| 64 bytes from 192.168.0.3: icmp_req=11 ttl=64 time=2.03 ms -| 64 bytes from 192.168.0.3: icmp_req=12 ttl=64 time=1.98 ms - -| B.A.T.M.A.N. IV: -| 1->2: 11 seconds -| 64 bytes from 192.168.0.3: icmp_req=34 ttl=64 time=1.88 ms -| 64 bytes from 192.168.0.3: icmp_req=35 ttl=64 time=1.07 ms -| 64 bytes from 192.168.0.3: icmp_req=46 ttl=64 time=1.94 ms -| 64 bytes from 192.168.0.3: icmp_req=47 ttl=64 time=2.02 ms -| 2->1: 3 seconds -| 64 bytes from 192.168.0.3: icmp_req=4 ttl=64 time=1.52 ms -| 64 bytes from 192.168.0.3: icmp_req=5 ttl=64 time=1.60 ms -| 64 bytes from 192.168.0.3: icmp_req=8 ttl=64 time=1.28 ms -| 64 bytes from 192.168.0.3: icmp_req=9 ttl=64 time=2.18 ms -| 1->2 (again): 7 seconds -| 64 bytes from 192.168.0.3: icmp_req=16 ttl=64 time=1.42 ms -| 64 bytes from 192.168.0.3: icmp_req=17 ttl=64 time=1.73 ms -| 64 bytes from 192.168.0.3: icmp_req=24 ttl=64 time=2.23 ms -| 64 bytes from 192.168.0.3: icmp_req=25 ttl=64 time=1.98 ms - -New distant neighbor -~~~~~~~~~~~~~~~~~~~~ - -|image5| - -| ping 192.168.0.6 -| kill $(cat killmeMOBILE.pid) ; \ -| wirefilter --daemon -v num0_7.ctl:num0_2.ctl --pidfile - killmeMOBILE.pid -| kill $(cat killmeMOBILE.pid) ; \ -| wirefilter --daemon -v num0_7.ctl:num0_1.ctl --pidfile - killmeMOBILE.pid - -| B.A.T.M.A.N. IV: -| 1->2: 11 seconds -| 64 bytes from 192.168.0.6: icmp_req=21 ttl=64 time=4.15 ms -| 64 bytes from 192.168.0.6: icmp_req=22 ttl=64 time=3.55 ms -| 64 bytes from 192.168.0.6: icmp_req=34 ttl=64 time=3.87 ms -| 64 bytes from 192.168.0.6: icmp_req=35 ttl=64 time=2.78 ms -| 2->1: 3 seconds -| 64 bytes from 192.168.0.6: icmp_req=42 ttl=64 time=4.29 ms -| 64 bytes from 192.168.0.6: icmp_req=43 ttl=64 time=1.31 ms -| 64 bytes from 192.168.0.6: icmp_req=44 ttl=64 time=1.91 ms -| 64 bytes from 192.168.0.6: icmp_req=47 ttl=64 time=3.68 ms -| 64 bytes from 192.168.0.6: icmp_req=48 ttl=64 time=3.57 ms -| 1->2: 11 seconds -| 64 bytes from 192.168.0.6: icmp_req=60 ttl=64 time=3.12 ms -| 64 bytes from 192.168.0.6: icmp_req=61 ttl=64 time=1.63 ms -| 64 bytes from 192.168.0.6: icmp_req=72 ttl=64 time=2.98 ms -| 64 bytes from 192.168.0.6: icmp_req=73 ttl=64 time=1.71 ms - -| B.A.T.M.A.N. V: -| 1->2: 6 seconds -| 64 bytes from 192.168.0.6: icmp_req=4 ttl=64 time=3.28 ms -| 64 bytes from 192.168.0.6: icmp_req=5 ttl=64 time=1.94 ms -| 64 bytes from 192.168.0.6: icmp_req=11 ttl=64 time=1.75 ms -| 64 bytes from 192.168.0.6: icmp_req=12 ttl=64 time=1.68 ms -| 2->1: 5 seconds -| 64 bytes from 192.168.0.6: icmp_req=25 ttl=64 time=3.01 ms -| 64 bytes from 192.168.0.6: icmp_req=26 ttl=64 time=2.09 ms -| 64 bytes from 192.168.0.6: icmp_req=31 ttl=64 time=2.48 ms -| 64 bytes from 192.168.0.6: icmp_req=32 ttl=64 time=2.10 ms -| 1->2: 5 seconds -| 64 bytes from 192.168.0.6: icmp_req=49 ttl=64 time=1.33 ms -| 64 bytes from 192.168.0.6: icmp_req=50 ttl=64 time=1.72 ms -| 64 bytes from 192.168.0.6: icmp_req=55 ttl=64 time=2.44 ms -| 64 bytes from 192.168.0.6: icmp_req=56 ttl=64 time=2.36 ms - -Mobile Node -~~~~~~~~~~~ - -|image6| - -| ping 192.168.0.6 -| kill $(cat killmeMOBILE.pid) ; \ -| wirefilter --daemon -v num0_7.ctl:num0_6.ctl --pidfile - killmeMOBILE.pid -| kill $(cat killmeMOBILE.pid) ; \ -| wirefilter --daemon -v num0_7.ctl:num0_5.ctl --pidfile - killmeMOBILE.pid -| kill $(cat killmeMOBILE.pid) ; \ -| wirefilter --daemon -v num0_7.ctl:num0_4.ctl --pidfile - killmeMOBILE.pid - -| B.A.T.M.A.N. IV: -| 6->5: 12 seconds -| 64 bytes from 192.168.0.6: icmp_req=7 ttl=64 time=1.23 ms -| 64 bytes from 192.168.0.6: icmp_req=8 ttl=64 time=0.913 ms -| 64 bytes from 192.168.0.6: icmp_req=20 ttl=64 time=1.11 ms -| 64 bytes from 192.168.0.6: icmp_req=21 ttl=64 time=1.69 ms -| 5->4: 11 seconds -| 64 bytes from 192.168.0.6: icmp_req=29 ttl=64 time=1.74 ms -| 64 bytes from 192.168.0.6: icmp_req=30 ttl=64 time=1.74 ms -| 64 bytes from 192.168.0.6: icmp_req=41 ttl=64 time=3.14 ms -| 64 bytes from 192.168.0.6: icmp_req=42 ttl=64 time=2.05 ms - -| B.A.T.M.A.N. V: -| 6 -> 5: 6 seconds -| 64 bytes from 192.168.0.6: icmp_req=38 ttl=64 time=1.29 ms -| 64 bytes from 192.168.0.6: icmp_req=39 ttl=64 time=1.43 ms -| 64 bytes from 192.168.0.6: icmp_req=45 ttl=64 time=1.28 ms -| 64 bytes from 192.168.0.6: icmp_req=46 ttl=64 time=1.20 ms -| 5 -> 4: 6 seconds -| 64 bytes from 192.168.0.6: icmp_req=49 ttl=64 time=1.10 ms -| 64 bytes from 192.168.0.6: icmp_req=50 ttl=64 time=0.550 ms -| 64 bytes from 192.168.0.6: icmp_req=56 ttl=64 time=2.13 ms -| 64 bytes from 192.168.0.6: icmp_req=57 ttl=64 time=3.05 ms - -.. |image0| image:: triangle.png -.. |image1| image:: circle.png -.. |image2| image:: circle-v2.png -.. |image3| image:: bottle.png -.. |image4| image:: new_neigh.png -.. |image5| image:: new_dist_neigh.png -.. |image6| image:: mob_node.png - diff --git a/batman-adv/Bandwidth_meter_tests.rst b/batman-adv/Bandwidth_meter_tests.rst deleted file mode 100644 index b402c48..0000000 --- a/batman-adv/Bandwidth_meter_tests.rst +++ /dev/null @@ -1,198 +0,0 @@ -Bandwidth meter tests -===================== - -In this page some sample result of the bw meter executions are reported. -In particular the results are compared with **iperf** and an **HTTP -download** to see how much the obtained throughput varies in the -different cases. - -All the experiments have been executed between two nodes, directly -connecteed via wireless ad-hoc. Different devices have been used for the -tests. Major details about this are given later. - -The scenarios where the tests have been executed are the following: - -#. bw meter from node to node -#. iperf from node to node. Iperf was running on the nodes themselves -#. HTTP download from an host behind the first node node to another one - behind the second node. In particular: - - #. host is connected to the Ethernet port of the node - #. Ethernet interface is bridged with the batman-adv soft interface - -Test in scenarios 1 and 2 were executed alternatively (one bw meter, one -iperf, one bw meter, one iperf, ...) while the HTTP downloads have been -executed all together later on. - -**note:** results given by the http download seem to be wrong. There is -probably something wrong in the setup which is slowing everything down. - -Environment 1 -------------- - -| One OM2P-HS and one OM2P-LC nodes using ath9k based wifi devices - connected in ad-hoc mode on **2.4GHz**. -| The HS is 802.11n (2x2) capable -| The LC is 802.11n (1x1) capable - -Results -~~~~~~~ - -| The table below shows the results in all the 3 scenarios. -| All the results are expressed in **Mbps**. - -**HS -> LC** - -+-------------+---------+---------+ -| bw_meter | iperf | http | -+=============+=========+=========+ -| 30.30 | 27.4 | 16.80 | -+-------------+---------+---------+ -| 30.02 | 27.4 | 16.80 | -+-------------+---------+---------+ -| 29.98 | 26.4 | 16.96 | -+-------------+---------+---------+ -| 30.69 | 26.8 | 16.96 | -+-------------+---------+---------+ -| 20.65 | 26.5 | 18.00 | -+-------------+---------+---------+ -| 30.26 | 26.7 | 17.28 | -+-------------+---------+---------+ -| 31.87 | 25.7 | 16.88 | -+-------------+---------+---------+ -| 19.35 | 26.2 | 16.32 | -+-------------+---------+---------+ -| 21.53 | 25.7 | 16.64 | -+-------------+---------+---------+ -| 30.78 | 26.2 | 16.56 | -+-------------+---------+---------+ -| 22.34 | 26.1 | 15.36 | -+-------------+---------+---------+ -| 31.81 | 26.3 | 16.16 | -+-------------+---------+---------+ -| 24.46 | 26.2 | 15.76 | -+-------------+---------+---------+ -| 23.02 | 27.0 | 16.40 | -+-------------+---------+---------+ -| 30.52 | 29.5 | 15.92 | -+-------------+---------+---------+ -| 30.48 | 33.8 | 16.24 | -+-------------+---------+---------+ -| 30.43 | 34.0 | 16.56 | -+-------------+---------+---------+ -| 20.56 | 34.1 | 16.48 | -+-------------+---------+---------+ -| 23.90 | 33.5 | 16.64 | -+-------------+---------+---------+ -| 22.95 | 33.9 | 17.04 | -+-------------+---------+---------+ - -**LC -> HS** - -+-------------+---------+---------+ -| bw_meter | iperf | http | -+=============+=========+=========+ -| 30.30 | 26.6 | 14.48 | -+-------------+---------+---------+ -| 30.46 | 26.6 | 14.40 | -+-------------+---------+---------+ -| 20.06 | 26.7 | 14.24 | -+-------------+---------+---------+ -| 21.98 | 26.3 | 14.40 | -+-------------+---------+---------+ -| 22.32 | 25.1 | 14.24 | -+-------------+---------+---------+ -| 30.90 | 25.0 | 14.48 | -+-------------+---------+---------+ -| 32.12 | 25.7 | 14.48 | -+-------------+---------+---------+ -| 21.72 | 26.5 | 14.48 | -+-------------+---------+---------+ -| 21.30 | 26.4 | 14.56 | -+-------------+---------+---------+ -| 31.02 | 25.4 | 14.64 | -+-------------+---------+---------+ -| 23.50 | 26.5 | 14.32 | -+-------------+---------+---------+ -| 22.54 | 26.1 | 14.48 | -+-------------+---------+---------+ -| 25.14 | 26.2 | 14.24 | -+-------------+---------+---------+ -| 20.89 | 25.0 | 14.40 | -+-------------+---------+---------+ -| 28.61 | 25.3 | 14.48 | -+-------------+---------+---------+ -| 28.30 | 25.7 | 14.32 | -+-------------+---------+---------+ -| 23.25 | 26.8 | 14.64 | -+-------------+---------+---------+ -| 29.35 | 26.0 | 14.32 | -+-------------+---------+---------+ -| 29.95 | 25.6 | 14.48 | -+-------------+---------+---------+ -| 29.16 | 26.4 | 14.40 | -+-------------+---------+---------+ - -Environment 2 -------------- - -| two OM5P node using ath9k based wifi devices connected in ad-hoc mode - on **5GHz** using **HT40+** (channel 40MHz wide). -| The OM5P is 802.11n (2x2) capable - -Results -~~~~~~~ - -| The table below shows the results in all the 3 scenarios. -| All the results are expressed in **Mbps**. - -For this environment, one more scenario has been tested: **iperf host to -host**, meaning that an iperf session has been launched between the two -hosts connected to the nodes (same configuration as the HTTP download -scenario). - -**OM5P -> OM5P** - -+-------------+---------+---------+-------------+ -| bw_meter | iperf | http | iperf/h2h | -+=============+=========+=========+=============+ -| 135.52 | 36.2 | 32.96 | 83.0 | -+-------------+---------+---------+-------------+ -| 144.46 | 36.6 | 33.28 | 80.6 | -+-------------+---------+---------+-------------+ -| 145.53 | 36.4 | 30.64 | 81.1 | -+-------------+---------+---------+-------------+ -| 162.07 | 36.5 | 28.96 | 82.5 | -+-------------+---------+---------+-------------+ -| 148.56 | 36.6 | 30.56 | 83.3 | -+-------------+---------+---------+-------------+ -| 156.16 | 36.5 | 29.52 | 80.4 | -+-------------+---------+---------+-------------+ -| 141.38 | 36.6 | 29.84 | 82.5 | -+-------------+---------+---------+-------------+ -| 161.64 | 36.6 | 29.36 | 81.9 | -+-------------+---------+---------+-------------+ -| 143.59 | 36.4 | 33.04 | 83.6 | -+-------------+---------+---------+-------------+ -| 163.20 | 36.5 | 29.20 | 83.8 | -+-------------+---------+---------+-------------+ -| 162.87 | 36.7 | 31.52 | 81.9 | -+-------------+---------+---------+-------------+ -| 163.94 | 36.6 | 30.16 | 80.1 | -+-------------+---------+---------+-------------+ -| 162.24 | 36.6 | 31.04 | 82.4 | -+-------------+---------+---------+-------------+ -| 143.91 | 36.5 | 30.80 | 80.6 | -+-------------+---------+---------+-------------+ -| 160.92 | 36.6 | 31.04 | 81.6 | -+-------------+---------+---------+-------------+ -| 148.86 | 36.6 | 31.12 | 84.2 | -+-------------+---------+---------+-------------+ -| 164.32 | 36.4 | 28.88 | 81.5 | -+-------------+---------+---------+-------------+ -| 142.23 | 36.4 | 27.92 | 81.6 | -+-------------+---------+---------+-------------+ -| 154.22 | 36.4 | 29.84 | 80.9 | -+-------------+---------+---------+-------------+ -| 153.94 | 36.4 | 30.64 | 82.4 | -+-------------+---------+---------+-------------+ diff --git a/batman-adv/Kmalloc-kmem-cache-tests.rst b/batman-adv/Kmalloc-kmem-cache-tests.rst deleted file mode 100644 index 6690be5..0000000 --- a/batman-adv/Kmalloc-kmem-cache-tests.rst +++ /dev/null @@ -1,273 +0,0 @@ -Kmalloc vs. Kmem-cache Tests -============================ - -1) Abstract ------------ - -In various, larger Freifunk mesh communities some issues happening after -a certain broadcast domain size threshold occured. 32MB of RAM devices -start to have load issues and reboot frequently with a `Gluon -2016.1.3 https://github.com/freifunk-gluon/gluon/`__ (batman-adv -2015.1) firmware `once they reach about 3100 -clients https://github.com/freifunk-gluon/gluon/issues/753`__ (3100 -entries in the global translation table). - -While several other changes probably introduced a higher memory usage -(e.g. switch to FQ-Codel with OpenWRT Chaos Calmer, larger kernel, ...), -too, the possibilities to increase efficiency of the translation table -by kmem-cache-alloc() instead of kmalloc() was considered and is the -focus and primary motivation of this article. - -Some information about kmem-cache can be found -`here https://static.lwn.net/images/pdf/LDD3/ch08.pdf`__. General -information about kmem-caches can usually be found in /proc/slabinfo (if -the kernel was compiled with slabinfo support). - --------------- - -The idea of these tests is to feed one 32MB RAM, embedded device with as -many global TT entries as possible from a second, more powerful device. -The test scripts continuously fetch the number of global TT entries -until the embedded device reboots due to an Out-of-Memory error. - -We then compare this count with various configurations, for instance -with kmalloc() vs. kmem-cache-alloc() vs. -kmem-cache-alloc(SLAB_HWCACHE_ALIGN). But also with wifi -enabled/disabled or full global TT dump + count vs. direct, global TT -count access. - -2) Test setup -------------- - -2.1) Hardware & Connectivity -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -|image0| - -The test setup consists of two machines: - -- WLAN-Mesh-Router: TP-Link TL-WR841ND v8, 32MB RAM, MIPS, ar71xx -- x86_64 PC: 3x ethernet interfaces, 8GB RAM - -Those two devices are connected via two network cables. One dedicated -for polling the status from and controlling the embedded device. The -other one dedicated for the batman-adv mesh. Finally the x86 PC has a -third ethernet interface for external access to control and monitor the -tests. - -2.2) Software & Configuration -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -- WLAN-Mesh-Router: - -| * Gluon v2016.1.3 -| * Gluon site config from Freifunk Rhein-Neckar, v0.5.4 -| * batman-adv v2016.1 - -- x86_64 PC: - -| * Debian Sid -| * 3.16.7 Linux kernel -| * batman-adv v2016.1 -| * Mausezahn v0.40 - -For the embedded device, WLAN-Mesh-Router, two patches were added to -Gluon/batman-adv: - -- Upgrade to batman-adv v2016.1 (Gluon / OpenWRT CC currently provides - v2015.1 for the package feed) -- Global translation table count patch (outputs the number of global TT - objects via debugfs directly) - -Next to these two patches, three variants for the image for the embedded -device were created: - -- kmalloc (vanilla, uses kmalloc() for TT) -- kmem-cache-aligned (Sven's original patch, with SLAB_HWCACHE_ALIGN - flag) -- kmem-cache-unaligned (Sven's patch but with no SLAB_HWCACHE_ALIGN - flag) - -3) Test runs ------------- - -The following configurations were tested. - -3.1) kmalloc vs. kmem-cache-alloc ("kmalloc" vs. "kmem-cache-aligned" vs. "kmem-cache-unaligned" runs) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Currently, batman-adv uses kmalloc() to allocate memory for a global -translation table. This option tries using dedicated kmem-caches for -local and global TT entries, as well as global TT orig entries via -Sven's patch. - -This test configuration also both tries using kmem-cache-alloc() with -and without setting the SLAB_HWCACHE_ALIGN flag. - -3.2) Wifi (hidden) vs. No Wifi ("nowifi" run) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Gluon, by default, provides both a mesh interface (either IBSS or -802.11s w/o fwd.; here: IBSS) for the mesh routing protocol. And a wifi -AP interface for clients to connect. - -Tests were performed once with these two wifi interfaces enabled, but -hidden. And once with no wifi interfaces (UCI wifi interface sections -disabled). - -3.3) Bridge FDB (Forwarding Database) enabled vs. disabled ("nofdb" run) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -By default, the bridge keeps track of behind which bridge port which MAC -address can be found. This information is stored in the so called -forwarding database, or FDB for short. - -This is similar to how batman-adv stores which client and according MAC -address can be found on which mesh node. And by that also not strictly -necessary for a bridged mesh network to function correctly. - -The bridge allows to disable the FDB learning on specific ports as well -as to configure on which ports ethernet frames with an unknown -destination MAC should be flooded. - -The "nofdb" test run disables learning on the bat0 bridge port and lets -the bridge simply flood frames with unknown destination to bat0. Then -batman-adv will determine via its global translation table if an -appropriate host in the mesh exists and if so, forwards the frame -further. - -3.4) Full Global Translation Table Dump vs. Count Dump only ("notg" run) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Currently batman-adv exports the global translation table via debugfs -(patches for netlink exports are currently work-in-progress). For the -export, one buffer to store the full, human-readable, ASCII-encoded -table is created where translation table information is copied into. - -Due to the human-readable format, a translation table with about four -thousand clients can easily need a 256KB buffer. Additionally, once the -buffer is full, the kernel will try to create a new buffer of double the -size and copy things over. This leads to noticeable, discrete jumps in -load and memory usage every time the number of mesh clients roughly -doubles. - -Further more, buffer allocations are first tried via kmalloc(), which -needs a consecutive memory area, which might be tricky for a 256KB or -512KB bulk on an embedded device without much spare RAM. Current kernel -versions (including Gluon v2016.1.3) will try to fallback to vmalloc() -which will allocate several smaller, scattered memory regions instead -once a kmalloc() fails with an -ENOMEM. - -Still, even with the recent vmalloc()-fallback patch, this debugfs -behaviour might create high loads or memory usage temporarily. - -Therefore a small, custom patch for batman-adv was added to provide just -the count of the global translation table via debugfs. The "notg" test -run then uses this new trans_table_global_count instead of a line -count of the full trans_table_global. - -4) Overview Test Procedure --------------------------- - -All combinations of the test runs described above (in total: 24) were -performed. They were run 30 times each to lower the standard error. - -The x86 PC performing the test runs creates 25 batman-adv instances. -Then the tool mausezahn sends 1500 frames with a random source MAC -address over each batman-adv instance, one by one with a short delay. -This will create about 25 times 1500 = 37500 global translation table -entries maximum. - -While mausezahn runs and the embedded device is reachable, the global -translation table size and /proc/meminfo is collected once every second -over ssh through the network interface dedicated for monitoring. - -5) Results (short) ------------------- - -5.1) Raw/Text -~~~~~~~~~~~~~ - - describes the average number of global TT entries of 30 test rounds -which could be created on a run until the node rebooted due to being -out-of-memory. - - is similar to the average number of TT entries, but filters out -outliers in the measurements. And can be an indicator on how convincing -the average is. - -Similarly, the is an indicator regarding whether the number of test -rounds was sufficiently large. - -:: - - $ ./eval-all.sh - : <# of Test Rounds> - - ## logs/kmalloc-01: - logs/kmalloc-01/_: 11366.666667 11466.000000 1286.673109 234.913295 30 - logs/kmalloc-01/nofdb: 11744.366667 12175.000000 1588.274567 289.977936 30 - logs/kmalloc-01/notg: 13318.066667 13486.500000 1613.411767 294.567340 30 - logs/kmalloc-01/notg-nofdb: 14900.266667 15748.500000 2565.820998 468.452680 30 - logs/kmalloc-01/nowifi: 15402.933333 15265.500000 1698.790804 310.155348 30 - logs/kmalloc-01/nowifi-nofdb: 16616.733333 16221.500000 1250.387751 228.288526 30 - logs/kmalloc-01/nowifi-notg: 19189.800000 19199.500000 857.763270 156.605431 30 - logs/kmalloc-01/nowifi-notg-nofdb: 21919.766667 22328.500000 840.369311 153.429743 30 - ## logs/kmem-cache-aligned-01: - logs/kmem-cache-aligned-01/_: 14849.133333 14631.000000 2521.004558 460.270355 30 - logs/kmem-cache-aligned-01/nofdb: 16657.200000 17596.500000 3056.207818 557.984654 30 - logs/kmem-cache-aligned-01/notg: 16289.800000 16961.500000 5142.746046 938.932672 30 - logs/kmem-cache-aligned-01/notg-nofdb: 21636.333333 23740.000000 4241.577987 774.402648 30 - logs/kmem-cache-aligned-01/nowifi: 21737.300000 21781.500000 1034.813386 188.930211 30 - logs/kmem-cache-aligned-01/nowifi-nofdb: 24014.933333 23901.000000 788.844130 144.022575 30 - logs/kmem-cache-aligned-01/nowifi-notg: 24083.300000 23984.500000 586.224084 107.029385 30 - logs/kmem-cache-aligned-01/nowifi-notg-nofdb: 26726.700000 26897.000000 1354.035971 247.212015 30 - ## logs/kmem-cache-unaligned-01: - logs/kmem-cache-unaligned-01/_: 14592.266667 14951.500000 3087.529724 563.703226 30 - logs/kmem-cache-unaligned-01/nofdb: 16375.633333 16065.500000 2291.323846 418.336586 30 - logs/kmem-cache-unaligned-01/notg: 16511.766667 17114.000000 3959.415493 722.887060 30 - logs/kmem-cache-unaligned-01/notg-nofdb: 22112.066667 23868.500000 3473.455781 634.163361 30 - logs/kmem-cache-unaligned-01/nowifi: 22368.566667 22648.500000 1172.829504 214.128392 30 - logs/kmem-cache-unaligned-01/nowifi-nofdb: 24047.266667 23558.500000 1195.256038 218.222898 30 - logs/kmem-cache-unaligned-01/nowifi-notg: 24636.566667 24545.500000 698.748915 127.573514 30 - logs/kmem-cache-unaligned-01/nowifi-notg-nofdb: 28171.033333 28426.500000 1802.042313 329.006408 30 - -5.2) kmalloc vs. kmem-cache -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The following diagram shows the gain factor for the number of global TT -entries between kmalloc and kmem-cache-aligned/unaligned. It is an -average of all test types (_, nofdb, notg, ... nowifi-notg-nofdb) and -rounds. So an average gain factor of various combinations with 240 -rounds in total. - -The median chart uses the median values from 5.1 instead of its average -values. - -|image1| - -:: - - $ ./eval+plot-kmalloc_vs_kmem-cache.sh - Size gain factor kmalloc-01 vs kmem-cache-aligned-01: - ave: 1.34133, med: 1.35506 - - Size gain factor kmalloc-01 vs kmem-cache-unaligned-01: - ave: 1.35879, med: 1.36195 - -6) Results (extended) ---------------------- - -7) Conclusion -------------- - -8) Appendix ------------ - -- Logs -- Test scripts -- `Images http://metameute.de/~tux/batman-adv/kmalloc_vs_kmem-cache/images.tar.xz`__ - -.. |image0| image:: kmalloc-kmem-cache-setup.png -.. |image1| image:: kmalloc_vs_kmem-cache.png - diff --git a/batman-adv/index.rst b/batman-adv/index.rst index 1fd41bd..91804f4 100644 --- a/batman-adv/index.rst +++ b/batman-adv/index.rst @@ -8,10 +8,8 @@ Contents:

Ap-isolation Bandwidth_meter_technical - Bandwidth_meter_tests Batman-adv-openwrt-config BATMAN_V - BATMAN_V_Tests Batman_v_throughput_experimental Bcast-hidden-node Bridge-loop-avoidance-II @@ -34,7 +32,6 @@ Contents: Faq Fragmentation-technical Gateways - Kmalloc-kmem-cache-tests LinuxNextTracking Multicast-ideas Multicast-ideas-updated diff --git a/batman-adv/kmalloc-kmem-cache-setup.dia b/batman-adv/kmalloc-kmem-cache-setup.dia deleted file mode 100644 index 0cc0cb5..0000000 Binary files a/batman-adv/kmalloc-kmem-cache-setup.dia and /dev/null differ diff --git a/batman-adv/kmalloc-kmem-cache-setup.png b/batman-adv/kmalloc-kmem-cache-setup.png deleted file mode 100644 index e90daee..0000000 Binary files a/batman-adv/kmalloc-kmem-cache-setup.png and /dev/null differ diff --git a/batman-adv/kmalloc_vs_kmem-cache.png b/batman-adv/kmalloc_vs_kmem-cache.png deleted file mode 100644 index 15774ce..0000000 Binary files a/batman-adv/kmalloc_vs_kmem-cache.png and /dev/null differ