commits July 2017

commits@lists.open-mesh.org

1 participants
1317 discussions

[doc] master: doc: Cleanup of alfred documentation (31d78e5)
by postmaster＠open-mesh.org 13 Jul '17

13 Jul '17

Repository : ssh://git@open-mesh.org/doc On branch : master >--------------------------------------------------------------- commit 31d78e541dd357ba56d838140b1a401cc1bcd0e7 Author: Sven Eckelmann <sven(a)narfation.org> Date: Thu Jul 13 23:17:37 2017 +0200 doc: Cleanup of alfred documentation Signed-off-by: Sven Eckelmann <sven(a)narfation.org> >--------------------------------------------------------------- 31d78e541dd357ba56d838140b1a401cc1bcd0e7 alfred/Alfred-gpsd.rst | 1 + alfred/Alfred-output-format-proposal.rst | 7 +- alfred/Alfred.rst | 131 ------------------------------- alfred/Alfred_architecture.rst | 50 ++++++------ alfred/Batadv-vis.rst | 1 + alfred/Building_information.rst | 36 ++++----- alfred/Wiki.rst | 50 ------------ alfred/index.rst | 44 ++++++++++- 8 files changed, 88 insertions(+), 232 deletions(-) diff --git a/alfred/Alfred-gpsd.rst b/alfred/Alfred-gpsd.rst index 0079490..1bfbbfb 100644 --- a/alfred/Alfred-gpsd.rst +++ b/alfred/Alfred-gpsd.rst @@ -1,3 +1,4 @@ +=========== Alfred-gpsd =========== diff --git a/alfred/Alfred-output-format-proposal.rst b/alfred/Alfred-output-format-proposal.rst index c86a5ea..302da52 100644 --- a/alfred/Alfred-output-format-proposal.rst +++ b/alfred/Alfred-output-format-proposal.rst @@ -1,3 +1,4 @@ +========================================= Alfred output format enhancement proposal ========================================= @@ -13,7 +14,7 @@ Here's a proposal which aims for the following three key benefits: - Binary data can be inserted, queried and piped on the shell. Valid UTF8 text only by default -------------------------------- +=============================== *Valid UTF8 text, ASCII, example 1:* @@ -78,7 +79,7 @@ Simply fail with an error return code and message, example: Invalid UTF8 input! Consider using --binary Binary mode switch ------------------- +================== *Store:* @@ -100,7 +101,7 @@ So '$ alfred -r 64' displays the data in base64 (or some other suitable, json string compatible format). Namespaces ----------- +========== *Store:* diff --git a/alfred/Alfred.rst b/alfred/Alfred.rst deleted file mode 100644 index 81db303..0000000 --- a/alfred/Alfred.rst +++ /dev/null @@ -1,131 +0,0 @@ -A.L.F.R.E.D - Almighty Lightweight Fact Remote Exchange Daemon -============================================================== - -| "alfred is a user space daemon to efficiently[tm] flood the network - with useless data - like vis, weather data, network notes, etc" -| > - Marek Lindner, 2012 - -Introduction ------------- - -alfred is a user space daemon for distributing arbitrary local -information over the mesh/network in a decentralized fashion. This data -can be anything which appears to be useful - originally designed to -replace the batman-adv visualization (vis), you may distribute -hostnames, phone books, administration information, DNS information, the -local weather forecast ... - -Typically, alfred runs as unix daemon in the background of the system. A -user may insert information by using the alfred binary on the command -line, or use custom written programs to communicate with alfred directly -through unix sockets. Once the local data is received, the alfred daemon -takes care of distributing this information to other alfred servers on -other nodes somewhere in the network. As addressing scheme IPv6 -link-local multicast addresses are used which do not require any manual -configuration. A user can request data from alfred, and will receive the -information available from all alfred servers in the network. - -See the -`README <https://git.open-mesh.org/alfred.git/blob_plain/refs/heads/master:/README>`__ -for more information or the -`manpage <https://downloads.open-mesh.org/batman/manpages/alfred.8.html>`__ -for usage. - -Further resources ------------------ - -| \* alfred slave on android: https://github.com/basros/alfreda -| \* Wireshark dissector for alfred: - https://github.com/basros/alfred-dissector -| \* [[alfred:alfred architecture\|Alfred architecture]] - technical - information about alfred - -Current applications --------------------- - -There are a few applications currently implemented on top of alfred: - -batadv-vis -~~~~~~~~~~ - -batadv-vis can be used to visualize your batman-adv mesh network. It -read the neighbor information and local client table and distributes -this information via alfred in the network. By gathering this local -information, any vis node can get the whole picture of the network. - -It allows output of different formats (json, graphviz) and replaces the -in-kernel vis functionality found in older batman-adv kernel modules -(<2014). See the sample picture below. For more information, please read -the vis section of the -`README <https://git.open-mesh.org/alfred.git/blob_plain/refs/heads/master:/README>`__ -or the -`manpage <https://downloads.open-mesh.org/batman/manpages/batadv-vis.html>`__ -for usage. - -|image0| - -alfred-gpsd -~~~~~~~~~~~ - -Alfred-gpsd can be used to distibute GPS location information about your -batman-adv mesh network. This information could be, for example, -combined with Vis to visualize your mesh topology with true geographic -layout. For mobile or nomadic nodes, Alfred-gpsd, can get location -information from gpsd. Alternatively, a static location can be passed on -the command line, which is useful for static nodes without a GPS. - -For more information, please read the alfred-gpsd section of the -`README <https://git.open-mesh.org/alfred.git/blob_plain/refs/heads/master:/README>`__ -or the -`manpage <https://downloads.open-mesh.org/batman/manpages/alfred-gpsd.html>`__ -for usage. - -Download --------- - -Release tarballs as well as snapshots are available: - -| \* release tarballs: - [[open-mesh:Download#Download-Released-Source-Code\|Check the Download - page]] -| \* git web directory: https://git.open-mesh.org/alfred.git -| \* git download: git clone git://git.open-mesh.org/alfred.git -| \* - snapshot:https://git.open-mesh.org/alfred.git/snapshot/refs/heads/master.ta… - -OpenWRT installation from routing feed -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Alfred is also part of the routing feed of OpenWRT. For newer OpenWRT, -just use: - -1. Install the alfred package: - -./scripts/feeds install alfred - -3. Run "make menuconfig" and select alfred (available under "Network ---->") - -OpenWRT development feed -~~~~~~~~~~~~~~~~~~~~~~~~ - -There is also a development packet feed for OpenWRT available for -alfred: - -1. add the alfred feed by adding the following line into your -feeds.conf: - -src-git batman git://git.open-mesh.org/openwrt-feed-devel.git - -2. Update and install the feed: - -| ./scripts/feeds update -| ./scripts/feeds install alfred - -3. Run "make menuconfig" and select alfred (available under "Network ---->") - -Finally, re-build Openwrt and enjoy using alfred! :) - -.. |image0| image:: batman-adv-vis-example.png - diff --git a/alfred/Alfred_architecture.rst b/alfred/Alfred_architecture.rst index 26f0a01..c8325e6 100644 --- a/alfred/Alfred_architecture.rst +++ b/alfred/Alfred_architecture.rst @@ -1,8 +1,9 @@ +=================== alfred architecture =================== Introduction ------------- +============ alfred is a user space daemon for distributing arbitrary local information over the mesh/network in a decentralized fashion. This data @@ -25,19 +26,18 @@ More user related information can be found in the [[alfred:Alfred]] overview page. Alfred specific terms ---------------------- - -+----------+--------------------------------------------------------------------------------------------------------------------------------------------+ -| node | a node is a device able to run alfred | -+----------+--------------------------------------------------------------------------------------------------------------------------------------------+ -| server | an alfred instance running on a node, able to communicate with alfred processes on other nodes and with clients running on the same node | -+----------+--------------------------------------------------------------------------------------------------------------------------------------------+ -| client | a program which supports the alfred protocol and communicates with the alfred server on the same node | -+----------+--------------------------------------------------------------------------------------------------------------------------------------------+ -| master | an alfred server process which stores incoming data, synchronizes it with other master servers and accepts requests/data from slaves | -+----------+--------------------------------------------------------------------------------------------------------------------------------------------+ -| slave | an alfred server process which only manages its own data, pushes/requests the data to/from **its** master server | -+----------+--------------------------------------------------------------------------------------------------------------------------------------------+ +===================== + +node + a node is a device able to run alfred +server + an alfred instance running on a node, able to communicate with alfred processes on other nodes and with clients running on the same node +client + a program which supports the alfred protocol and communicates with the alfred server on the same node +master + an alfred server process which stores incoming data, synchronizes it with other master servers and accepts requests/data from slaves +slave + an alfred server process which only manages its own data, pushes/requests the data to/from **its** master server Network ------- @@ -64,7 +64,7 @@ best master server to request data when required and to push the data from local clients to the alfred network through master servers. Network layer -~~~~~~~~~~~~~ +------------- All communication between servers in an alfred network is done through IPv6 link-local UDP messages. This only allows communication in the @@ -84,7 +84,7 @@ All the messages are sent through the IANA unregistered UDP/IPv6 port 0x4242 (in decimal: 16962). Detection of neighbors -~~~~~~~~~~~~~~~~~~~~~~ +---------------------- The master server will announce itself using IPv6 link-local multicast messages. This makes it possible to reach all nodes with a single @@ -115,7 +115,7 @@ Detected neighbor servers are automatically dropped after a timeout of 60s since the last announcement was received. Client data exchange -~~~~~~~~~~~~~~~~~~~~ +-------------------- The client communication to the alfred server is done through unix sockets on the same node. The path is defined as /var/run/alfred.sock @@ -161,7 +161,7 @@ The best practice for a client is to implement the handling of error messages even when it is only used together with master servers. Synchronization -~~~~~~~~~~~~~~~ +--------------- Data synchronizations are done master2master and slave2master. The slave will only send data from its clients to a single server. Master servers @@ -187,10 +187,10 @@ Data is automatically pruned from the server storage 600s after the last time it was received/refreshed. Packet formats --------------- +============== General format -~~~~~~~~~~~~~~ +-------------- The data stored in the packet headers is always stored in network byte order (big endian). The packet format is TLV based (type, value, length) @@ -208,7 +208,7 @@ The version field is also only defined for the outer TLV and has to be 0 for the specified first packet format. Master announcement -~~~~~~~~~~~~~~~~~~~ +------------------- |image6| @@ -218,7 +218,7 @@ more information. The receiver has to calculate the mac address of the sender by decoding the link-local IPv6 sender address. Request data -~~~~~~~~~~~~ +------------ |image7| @@ -233,7 +233,7 @@ The transaction id must be unique during the time the request is made and answered. Finish transaction -~~~~~~~~~~~~~~~~~~ +------------------ |image8| @@ -245,7 +245,7 @@ packets has to be equal to the number of alfred\_push\_data packets with the same transaction id to accept the transaction as successful. Inform about an error -~~~~~~~~~~~~~~~~~~~~~ +--------------------- Slave servers send error messages via unix sockets to clients. This tells the client that the request of data from the master server failed. @@ -257,7 +257,7 @@ alfred\_request packet. The only currently used error code is 1. Push data -~~~~~~~~~ +--------- Push data packets are sent/received by clients to send data via unix sockets to/from servers. Clients send it to store data on a server. diff --git a/alfred/Batadv-vis.rst b/alfred/Batadv-vis.rst index e44869b..64914d2 100644 --- a/alfred/Batadv-vis.rst +++ b/alfred/Batadv-vis.rst @@ -1,3 +1,4 @@ +========== Batadv-vis ========== diff --git a/alfred/Building_information.rst b/alfred/Building_information.rst index 5a8e441..9ea7d55 100644 --- a/alfred/Building_information.rst +++ b/alfred/Building_information.rst @@ -1,46 +1,44 @@ +==================== Building information ==================== Release tarballs as well as snapshots are available: -| \* release tarballs: +* release tarballs: [[open-mesh:Download#Download-Released-Source-Code\|Check the Download page]] -| \* git web directory: https://git.open-mesh.org/alfred.git -| \* git download: git clone git://git.open-mesh.org/alfred.git -| \* - snapshot:https://git.open-mesh.org/alfred.git/snapshot/refs/heads/master.ta… +* git web directory: https://git.open-mesh.org/alfred.git +* git download: ``git clone git://git.open-mesh.org/alfred.git`` +* `snapshot <https://git.open-mesh.org/alfred.git/snapshot/refs/heads/master.tar.gz>`__ OpenWRT installation from routing feed -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +====================================== Alfred is also part of the routing feed of OpenWRT. For newer OpenWRT, just use: -1. Install the alfred package: +#. Install the alfred package:: -./scripts/feeds install alfred + ./scripts/feeds install alfred -3. Run "make menuconfig" and select alfred (available under "Network ---->") +#. Run "make menuconfig" and select alfred (available under ``Network --->``) OpenWRT development feed -~~~~~~~~~~~~~~~~~~~~~~~~ +======================== There is also a development packet feed for OpenWRT available for alfred: -1. add the alfred feed by adding the following line into your -feeds.conf: +#. add the alfred feed by adding the following line into your + feeds.conf:: -src-git batman git://git.open-mesh.org/openwrt-feed-devel.git + src-git batman git://git.open-mesh.org/openwrt-feed-devel.git -2. Update and install the feed: +#. Update and install the feed:: -| ./scripts/feeds update -| ./scripts/feeds install alfred + ./scripts/feeds update + ./scripts/feeds install alfred -3. Run "make menuconfig" and select alfred (available under "Network ---->") +#. Run ``make menuconfig`` and select alfred (available under ``Network --->``) Finally, re-build Openwrt and enjoy using alfred! :) diff --git a/alfred/Wiki.rst b/alfred/Wiki.rst deleted file mode 100644 index b75e15e..0000000 --- a/alfred/Wiki.rst +++ /dev/null @@ -1,50 +0,0 @@ -A.L.F.R.E.D - Almighty Lightweight Fact Remote Exchange Daemon -============================================================== - -"alfred is a user space daemon to efficiently[tm] flood the network with -useless data - like vis, weather data, network notes, etc" - -- Marek Lindner, 2012 - -alfred is a user space daemon for distributing arbitrary local -information over the mesh/network in a decentralized fashion. This data -can be anything which appears to be useful - originally designed to -replace the batman-adv visualization (vis), you may distribute -hostnames, phone books, administration information, DNS information, the -local weather forecast ... - -Typically, alfred runs as unix daemon in the background of the system. A -user may insert information by using the alfred binary on the command -line, or use custom written programs to communicate with alfred directly -through unix sockets. Once the local data is received, the alfred daemon -takes care of distributing this information to other alfred servers on -other nodes somewhere in the network. As addressing scheme IPv6 -link-local multicast addresses are used which do not require any manual -configuration. A user can request data from alfred, and will receive the -information available from all alfred servers in the network. - -See the -`README <https://git.open-mesh.org/alfred.git/blob_plain/refs/heads/master:/README>`__ -for more information or the -`manpage <https://downloads.open-mesh.org/batman/manpages/alfred.8.html>`__ -for usage. - -Getting started ---------------- - -| \* [[Building information]] - how to download and build alfred -| \* [[batadv-vis]] - Tool to visualize batman-adv networks -| \* [[alfred-gpsd]] - Share geolocation of mesh nodes - -Developer information ---------------------- - -\* [[Alfred architecture]] - information about topologies, internal -architecture and packet format - -Further resources ------------------ - -| \* alfred slave on android: https://github.com/basros/alfreda -| \* Wireshark dissector for alfred: - https://github.com/basros/alfred-dissector diff --git a/alfred/index.rst b/alfred/index.rst index e1e3aea..3c5dedf 100644 --- a/alfred/index.rst +++ b/alfred/index.rst @@ -1,13 +1,16 @@ -alfred -====== +A.L.F.R.E.D - Almighty Lightweight Fact Remote Exchange Daemon +============================================================== + + "alfred is a user space daemon to efficiently[tm] flood the network with + useless data - like vis, weather data, network notes, etc" + + - Marek Lindner, 2012 Contents: .. toctree:: :maxdepth: 2 - Wiki - Alfred gettingstarted developerinformation @@ -17,3 +20,36 @@ Contents: ======= * :ref:`genindex` + +Introduction +------------ + +alfred is a user space daemon for distributing arbitrary local +information over the mesh/network in a decentralized fashion. This data +can be anything which appears to be useful - originally designed to +replace the batman-adv visualization (vis), you may distribute +hostnames, phone books, administration information, DNS information, the +local weather forecast ... + +Typically, alfred runs as unix daemon in the background of the system. A +user may insert information by using the alfred binary on the command +line, or use custom written programs to communicate with alfred directly +through unix sockets. Once the local data is received, the alfred daemon +takes care of distributing this information to other alfred servers on +other nodes somewhere in the network. As addressing scheme IPv6 +link-local multicast addresses are used which do not require any manual +configuration. A user can request data from alfred, and will receive the +information available from all alfred servers in the network. + +See the +`README <https://git.open-mesh.org/alfred.git/blob_plain/refs/heads/master:/README>`__ +for more information or the +`manpage <https://downloads.open-mesh.org/batman/manpages/alfred.8.html>`__ +for usage. + +Further resources +----------------- + +* alfred slave on android: https://github.com/basros/alfreda +* Wireshark dissector for alfred: + https://github.com/basros/alfred-dissector

1 0

[doc] master: doc: Remove call to TOC redmine macro (f53c3ba)
by postmaster＠open-mesh.org 13 Jul '17

13 Jul '17

Repository : ssh://git@open-mesh.org/doc On branch : master >--------------------------------------------------------------- commit f53c3ba4c66ef125e13fe299c6239761496995b4 Author: Sven Eckelmann <sven(a)narfation.org> Date: Thu Jul 13 22:56:38 2017 +0200 doc: Remove call to TOC redmine macro Signed-off-by: Sven Eckelmann <sven(a)narfation.org> >--------------------------------------------------------------- f53c3ba4c66ef125e13fe299c6239761496995b4 alfred/Alfred.rst | 2 -- alfred/Alfred_architecture.rst | 2 -- alfred/Wiki.rst | 2 -- batman-adv/BATMAN_V.rst | 2 -- batman-adv/Batman-adv-openwrt-config.rst | 2 -- batman-adv/Debian_batman-adv_AutoStartup.rst | 2 -- batman-adv/Doc-overview.rst | 2 -- batman-adv/Faq.rst | 2 -- batman-adv/Quick-start-guide.rst | 2 -- batman-adv/TVLV.rst | 2 -- batmand/Faq.rst | 2 -- open-mesh/Joker.rst | 2 -- 12 files changed, 24 deletions(-) diff --git a/alfred/Alfred.rst b/alfred/Alfred.rst index 0ed1203..81db303 100644 --- a/alfred/Alfred.rst +++ b/alfred/Alfred.rst @@ -5,8 +5,6 @@ A.L.F.R.E.D - Almighty Lightweight Fact Remote Exchange Daemon with useless data - like vis, weather data, network notes, etc" | > - Marek Lindner, 2012 -{{TOC}} - Introduction ------------ diff --git a/alfred/Alfred_architecture.rst b/alfred/Alfred_architecture.rst index 80777a6..26f0a01 100644 --- a/alfred/Alfred_architecture.rst +++ b/alfred/Alfred_architecture.rst @@ -1,8 +1,6 @@ alfred architecture =================== -{{>toc}} - Introduction ------------ diff --git a/alfred/Wiki.rst b/alfred/Wiki.rst index 1e7dc99..b75e15e 100644 --- a/alfred/Wiki.rst +++ b/alfred/Wiki.rst @@ -6,8 +6,6 @@ useless data - like vis, weather data, network notes, etc" - Marek Lindner, 2012 -{{TOC}} - alfred is a user space daemon for distributing arbitrary local information over the mesh/network in a decentralized fashion. This data can be anything which appears to be useful - originally designed to diff --git a/batman-adv/BATMAN_V.rst b/batman-adv/BATMAN_V.rst index fedb702..171ab70 100644 --- a/batman-adv/BATMAN_V.rst +++ b/batman-adv/BATMAN_V.rst @@ -6,8 +6,6 @@ between B.A.T.M.A.N. IV and B.A.T.M.A.N. V. Links to the technical documentation for further reading are provided at the end of this document. -{{toc}} - Separating neighbor discovery from mesh routing ----------------------------------------------- diff --git a/batman-adv/Batman-adv-openwrt-config.rst b/batman-adv/Batman-adv-openwrt-config.rst index 34e5d50..6928a40 100644 --- a/batman-adv/Batman-adv-openwrt-config.rst +++ b/batman-adv/Batman-adv-openwrt-config.rst @@ -1,8 +1,6 @@ B.A.T.M.A.N. OpenWrt configuration ================================== -{{>toc}} - This page showcases some basic batman-adv configurations on OpenWrt including wireless & network setups. However, the goal is to provide not more than a starting point. For a full reference of the OpenWrt uci diff --git a/batman-adv/Debian_batman-adv_AutoStartup.rst b/batman-adv/Debian_batman-adv_AutoStartup.rst index ebbbe97..8aff313 100644 --- a/batman-adv/Debian_batman-adv_AutoStartup.rst +++ b/batman-adv/Debian_batman-adv_AutoStartup.rst @@ -1,8 +1,6 @@ Debian batman-adv AutoStartup ============================= -{{>toc}} - This Page describes how to configure a Debian (or Derived Distribution like Ubuntu, Mint, etc) so that batman-adv starts automatically on boot up. First we'll start the the same "Simple mesh network" example from diff --git a/batman-adv/Doc-overview.rst b/batman-adv/Doc-overview.rst index 9ffa302..9c31003 100644 --- a/batman-adv/Doc-overview.rst +++ b/batman-adv/Doc-overview.rst @@ -1,8 +1,6 @@ B.A.T.M.A.N. Advanced Documentation Overview ============================================ -{{TOC}} - How to get a mesh network up and running, how to configure the many features of B.A.T.M.A.N. Advanced, and how to shoot down your troubles. diff --git a/batman-adv/Faq.rst b/batman-adv/Faq.rst index 412c1d0..5ae4b73 100644 --- a/batman-adv/Faq.rst +++ b/batman-adv/Faq.rst @@ -1,8 +1,6 @@ FAQ === -{{TOC}} - Below you can see a list of frequently asked questions and answers. If your question is not listed below, please contact us. You can contact us via IRC: `#batman diff --git a/batman-adv/Quick-start-guide.rst b/batman-adv/Quick-start-guide.rst index b07c217..9b8901f 100644 --- a/batman-adv/Quick-start-guide.rst +++ b/batman-adv/Quick-start-guide.rst @@ -1,8 +1,6 @@ B.A.T.M.A.N. Advanced quick start guide ======================================= -{{>toc}} - This page shall show a couple of easy examples of how to use and setup a mesh network with B.A.T.M.A.N.-Advanced (further referenced as batman-adv). It is assumed, the tool 'batctl' was installed which allows diff --git a/batman-adv/TVLV.rst b/batman-adv/TVLV.rst index 7726b86..0732fc5 100644 --- a/batman-adv/TVLV.rst +++ b/batman-adv/TVLV.rst @@ -6,8 +6,6 @@ contains a list of TVLV definitions for reference. Be sure to have read the [[open-mesh:2012-10-01-GSoC-2012-Spyros-Gasteros-Final-Report\|TVLV introduction]] if you don't understand the scope of this document. -{{TOC}} - TVLV format ----------- diff --git a/batmand/Faq.rst b/batmand/Faq.rst index 24d578b..acf7363 100644 --- a/batmand/Faq.rst +++ b/batmand/Faq.rst @@ -1,8 +1,6 @@ FAQ === -{{TOC}} - See below a list of batmand (B.A.T.M.A.N. deamon) related questions and answers. diff --git a/open-mesh/Joker.rst b/open-mesh/Joker.rst index 0f9e3bf..77d0f25 100644 --- a/open-mesh/Joker.rst +++ b/open-mesh/Joker.rst @@ -1,8 +1,6 @@ T H E J O K E R - B.A.T.M.A.N.'s arch nemesis ============================================= -{{TOC}} - Introduction ------------

1 0

[doc] master: doc: batman-adv: Copy categories from overview page (8b7cf9b)
by postmaster＠open-mesh.org 13 Jul '17

13 Jul '17

Repository : ssh://git@open-mesh.org/doc On branch : master >--------------------------------------------------------------- commit 8b7cf9bb5588a3dc6806c5ed06a3846dda2de04b Author: Sven Eckelmann <sven(a)narfation.org> Date: Thu Jul 13 22:48:54 2017 +0200 doc: batman-adv: Copy categories from overview page Signed-off-by: Sven Eckelmann <sven(a)narfation.org> >--------------------------------------------------------------- 8b7cf9bb5588a3dc6806c5ed06a3846dda2de04b {alfred => batman-adv}/developerinformation.rst | 9 +++- batman-adv/features.rst | 23 ++++++++++ batman-adv/gettingstarted.rst | 24 +++++++++++ batman-adv/index.rst | 56 +++---------------------- batman-adv/protocol_information.rst | 28 +++++++++++++ batman-adv/random.rst | 34 +++++++++++++++ 6 files changed, 121 insertions(+), 53 deletions(-) diff --git a/alfred/developerinformation.rst b/batman-adv/developerinformation.rst similarity index 51% copy from alfred/developerinformation.rst copy to batman-adv/developerinformation.rst index f527ca9..653adca 100644 --- a/alfred/developerinformation.rst +++ b/batman-adv/developerinformation.rst @@ -7,8 +7,13 @@ Contents: .. toctree:: :maxdepth: 2 - Alfred_architecture - Alfred-output-format-proposal + Tweaking + Uevent + TVLV + Bandwidth_meter_technical + Batman_v_throughput_experimental + Bridge-loop-avoidance-Protocol + Bridge-loop-avoidance-Testcases .. only:: subproject diff --git a/batman-adv/features.rst b/batman-adv/features.rst new file mode 100644 index 0000000..56c17e8 --- /dev/null +++ b/batman-adv/features.rst @@ -0,0 +1,23 @@ +======== +Features +======== + +Contents: + +.. toctree:: + :maxdepth: 2 + + Gateways + Bridge-loop-avoidance + Multi-link-optimize + Ap-isolation + DistributedArpTable + Multicast-optimizations + NetworkCoding + +.. only:: subproject + + Indices + ======= + + * :ref:`genindex` diff --git a/batman-adv/gettingstarted.rst b/batman-adv/gettingstarted.rst new file mode 100644 index 0000000..3c167ab --- /dev/null +++ b/batman-adv/gettingstarted.rst @@ -0,0 +1,24 @@ +=============== +Getting Started +=============== + +Contents: + +.. toctree:: + :maxdepth: 2 + + Building-with-openwrt + Quick-start-guide + Using-batctl + Faq + Understand-your-batman-adv-network + Troubleshooting + Batman-adv-openwrt-config + Debian_batman-adv_AutoStartup + +.. only:: subproject + + Indices + ======= + + * :ref:`genindex` diff --git a/batman-adv/index.rst b/batman-adv/index.rst index 91804f4..dbe52d7 100644 --- a/batman-adv/index.rst +++ b/batman-adv/index.rst @@ -6,59 +6,13 @@ Contents: .. toctree:: :maxdepth: 2 - Ap-isolation - Bandwidth_meter_technical - Batman-adv-openwrt-config - BATMAN_V - Batman_v_throughput_experimental - Bcast-hidden-node - Bridge-loop-avoidance-II - Bridge-loop-avoidance-Protocol - Bridge-loop-avoidance - Bridge-loop-avoidance-Testcases - Broadcast-Avoidances-NHH-Assessment - Broadcast-Avoidances - Building-with-openwrt - Client-announcement - Client-roaming - Compatversion - Connecting-Batman-adv-clouds - Debian_batman-adv_AutoStartup - DistributedArpTable - DistributedArpTable-technical Doc-overview - ELP - Extended-isolation - Faq - Fragmentation-technical - Gateways - LinuxNextTracking - Multicast-ideas - Multicast-ideas-updated - Multicast-optimizations-bridges - Multicast-optimizations-flags - Multicast-optimizations-listener-reports - Multicast-optimizations-report-suppresion - Multicast-optimizations - Multicast-optimizations-tech - Multi-link-optimize - NetworkCoding - NetworkCoding-technical - Network-wide-multi-link-optimization - OGM - OGMv2 - Packet-types - Quick-start-guide - RIP - Throughput_meter - Troubleshooting - TT-Flags - TVLV - Tweaking - Uevent - Understand-your-batman-adv-network - Using-batctl Wiki + gettingstarted + features + developerinformation + protocol_information + random .. only:: subproject diff --git a/batman-adv/protocol_information.rst b/batman-adv/protocol_information.rst new file mode 100644 index 0000000..281b2c8 --- /dev/null +++ b/batman-adv/protocol_information.rst @@ -0,0 +1,28 @@ +==================== +Protocol Information +==================== + +Contents: + +.. toctree:: + :maxdepth: 2 + + Network-wide-multi-link-optimization + Client-announcement + Client-roaming + TT-Flags + Packet-types + Compatversion + BATMAN_V + Bridge-loop-avoidance-II + DistributedArpTable-technical + Fragmentation-technical + Multicast-optimizations-tech + NetworkCoding-technical + +.. only:: subproject + + Indices + ======= + + * :ref:`genindex` diff --git a/batman-adv/random.rst b/batman-adv/random.rst new file mode 100644 index 0000000..a275b6e --- /dev/null +++ b/batman-adv/random.rst @@ -0,0 +1,34 @@ +====== +Random +====== + +Contents: + +.. toctree:: + :maxdepth: 2 + + Bcast-hidden-node + Broadcast-Avoidances + Broadcast-Avoidances-NHH-Assessment + Connecting-Batman-adv-clouds + LinuxNextTracking + + ELP + Extended-isolation + Multicast-ideas + Multicast-ideas-updated + Multicast-optimizations-bridges + Multicast-optimizations-flags + Multicast-optimizations-listener-reports + Multicast-optimizations-report-suppresion + OGM + OGMv2 + RIP + Throughput_meter + +.. only:: subproject + + Indices + ======= + + * :ref:`genindex`

1 0

[doc] master: doc: alfred: Copy categories from overview page (2193e22)
by postmaster＠open-mesh.org 13 Jul '17

13 Jul '17

Repository : ssh://git@open-mesh.org/doc On branch : master >--------------------------------------------------------------- commit 2193e226bfa14b7e9750c32a0181bc9f5dd99ad1 Author: Sven Eckelmann <sven(a)narfation.org> Date: Thu Jul 13 22:23:51 2017 +0200 doc: alfred: Copy categories from overview page Signed-off-by: Sven Eckelmann <sven(a)narfation.org> >--------------------------------------------------------------- 2193e226bfa14b7e9750c32a0181bc9f5dd99ad1 {batmand => alfred}/developerinformation.rst | 6 ++---- {batmand => alfred}/gettingstarted.rst | 7 +++---- alfred/index.rst | 9 +++------ 3 files changed, 8 insertions(+), 14 deletions(-) diff --git a/batmand/developerinformation.rst b/alfred/developerinformation.rst similarity index 75% copy from batmand/developerinformation.rst copy to alfred/developerinformation.rst index 4d9ca4e..f527ca9 100644 --- a/batmand/developerinformation.rst +++ b/alfred/developerinformation.rst @@ -7,10 +7,8 @@ Contents: .. toctree:: :maxdepth: 2 - RoutingVodoo - DebugOutput - VisOutput - Coredump + Alfred_architecture + Alfred-output-format-proposal .. only:: subproject diff --git a/batmand/gettingstarted.rst b/alfred/gettingstarted.rst similarity index 71% copy from batmand/gettingstarted.rst copy to alfred/gettingstarted.rst index 788f829..12effcf 100644 --- a/batmand/gettingstarted.rst +++ b/alfred/gettingstarted.rst @@ -7,10 +7,9 @@ Contents: .. toctree:: :maxdepth: 2 - InternetTuning - VisualizeMesh - AnnouncingNetworks - Faq + Building_information + Batadv-vis + Alfred-gpsd .. only:: subproject diff --git a/alfred/index.rst b/alfred/index.rst index fd40deb..e1e3aea 100644 --- a/alfred/index.rst +++ b/alfred/index.rst @@ -6,13 +6,10 @@ Contents: .. toctree:: :maxdepth: 2 - Alfred_architecture - Alfred-gpsd - Alfred-output-format-proposal - Alfred - Batadv-vis - Building_information Wiki + Alfred + gettingstarted + developerinformation .. only:: subproject

1 0

[doc] master: doc: batmand: Copy categories from overview page (f068125)
by postmaster＠open-mesh.org 13 Jul '17

13 Jul '17

Repository : ssh://git@open-mesh.org/doc On branch : master >--------------------------------------------------------------- commit f0681259eb2c43d1177fa3337f05550ff81c7607 Author: Sven Eckelmann <sven(a)narfation.org> Date: Thu Jul 13 22:17:29 2017 +0200 doc: batmand: Copy categories from overview page Signed-off-by: Sven Eckelmann <sven(a)narfation.org> >--------------------------------------------------------------- f0681259eb2c43d1177fa3337f05550ff81c7607 batmand/{index.rst => developerinformation.rst} | 16 +++++----------- batmand/{index.rst => gettingstarted.rst} | 16 +++++----------- batmand/{index.rst => history.rst} | 12 ++---------- batmand/index.rst | 13 +++---------- 4 files changed, 15 insertions(+), 42 deletions(-) diff --git a/batmand/index.rst b/batmand/developerinformation.rst similarity index 54% copy from batmand/index.rst copy to batmand/developerinformation.rst index 50b46d4..4d9ca4e 100644 --- a/batmand/index.rst +++ b/batmand/developerinformation.rst @@ -1,22 +1,16 @@ -batmand -======= +===================== +Developer Information +===================== Contents: .. toctree:: :maxdepth: 2 - AnnouncingNetworks - BerlinExperience - Coredump - DebugOutput - Doc-overview - Faq - InternetTuning RoutingVodoo + DebugOutput VisOutput - VisualizeMesh - Why-starting-batman + Coredump .. only:: subproject diff --git a/batmand/index.rst b/batmand/gettingstarted.rst similarity index 57% copy from batmand/index.rst copy to batmand/gettingstarted.rst index 50b46d4..788f829 100644 --- a/batmand/index.rst +++ b/batmand/gettingstarted.rst @@ -1,22 +1,16 @@ -batmand -======= +=============== +Getting Started +=============== Contents: .. toctree:: :maxdepth: 2 - AnnouncingNetworks - BerlinExperience - Coredump - DebugOutput - Doc-overview - Faq InternetTuning - RoutingVodoo - VisOutput VisualizeMesh - Why-starting-batman + AnnouncingNetworks + Faq .. only:: subproject diff --git a/batmand/index.rst b/batmand/history.rst similarity index 52% copy from batmand/index.rst copy to batmand/history.rst index 50b46d4..9b26d78 100644 --- a/batmand/index.rst +++ b/batmand/history.rst @@ -1,4 +1,5 @@ -batmand +======= +History ======= Contents: @@ -6,16 +7,7 @@ Contents: .. toctree:: :maxdepth: 2 - AnnouncingNetworks BerlinExperience - Coredump - DebugOutput - Doc-overview - Faq - InternetTuning - RoutingVodoo - VisOutput - VisualizeMesh Why-starting-batman .. only:: subproject diff --git a/batmand/index.rst b/batmand/index.rst index 50b46d4..7349888 100644 --- a/batmand/index.rst +++ b/batmand/index.rst @@ -6,17 +6,10 @@ Contents: .. toctree:: :maxdepth: 2 - AnnouncingNetworks - BerlinExperience - Coredump - DebugOutput Doc-overview - Faq - InternetTuning - RoutingVodoo - VisOutput - VisualizeMesh - Why-starting-batman + gettingstarted + history + developerinformation .. only:: subproject

1 0

[doc] master: doc: Remove links to module related index/search files (8b2120d)
by postmaster＠open-mesh.org 13 Jul '17

13 Jul '17

Repository : ssh://git@open-mesh.org/doc On branch : master >--------------------------------------------------------------- commit 8b2120dd5acbccd7679d0cc6962c4ba893cb170a Author: Sven Eckelmann <sven(a)narfation.org> Date: Thu Jul 13 21:40:56 2017 +0200 doc: Remove links to module related index/search files Signed-off-by: Sven Eckelmann <sven(a)narfation.org> >--------------------------------------------------------------- 8b2120dd5acbccd7679d0cc6962c4ba893cb170a index.rst | 8 -------- 1 file changed, 8 deletions(-) diff --git a/index.rst b/index.rst index 7f88ade..21ea382 100644 --- a/index.rst +++ b/index.rst @@ -15,11 +15,3 @@ Contents: alfred/index batmand/index open-mesh/index - -Indices and tables -================== - -* :ref:`genindex` -* :ref:`modindex` -* :ref:`search` -

1 0

[doc] master: doc: Fix pages with multiple titles (dad4993)
by postmaster＠open-mesh.org 13 Jul '17

13 Jul '17

Repository : ssh://git@open-mesh.org/doc On branch : master >--------------------------------------------------------------- commit dad4993debc2575f4f4fcb882050d2350415151d Author: Sven Eckelmann <sven(a)narfation.org> Date: Thu Jul 13 21:38:27 2017 +0200 doc: Fix pages with multiple titles Signed-off-by: Sven Eckelmann <sven(a)narfation.org> >--------------------------------------------------------------- dad4993debc2575f4f4fcb882050d2350415151d batman-adv/Bcast-hidden-node.rst | 1 + batman-adv/Broadcast-Avoidances.rst | 48 +++++----- batman-adv/OGM.rst | 177 ++++++++++++++++++------------------ open-mesh/Gsoc2010-ideas.rst | 4 + open-mesh/New_papers.rst | 4 + open-mesh/WikiStart.rst | 1 + 6 files changed, 119 insertions(+), 116 deletions(-) diff --git a/batman-adv/Bcast-hidden-node.rst b/batman-adv/Bcast-hidden-node.rst index 88d9bee..b8c1ebb 100644 --- a/batman-adv/Bcast-hidden-node.rst +++ b/batman-adv/Bcast-hidden-node.rst @@ -1,3 +1,4 @@ +=================== Hidden Node Problem =================== diff --git a/batman-adv/Broadcast-Avoidances.rst b/batman-adv/Broadcast-Avoidances.rst index 5e1c28a..b7f8900 100644 --- a/batman-adv/Broadcast-Avoidances.rst +++ b/batman-adv/Broadcast-Avoidances.rst @@ -1,3 +1,4 @@ +==================== Broadcast Avoidances ==================== @@ -23,18 +24,18 @@ and by that reducing the OGM and broadcast packet overhead. (O (m\*n) => O (m) ) Goal ----- +==== - Reducing OGM2 and broadcast packet overhead Scenarios ---------- +========= Here are a few scenarios that the protocol additions described later are supposed to improve: A) Large, Transitive Link Domains -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +--------------------------------- |image1| @@ -63,7 +64,7 @@ All devices connected "see" each other on their network interface directly, usually with the same full-duplex link speed even. B) Gathering of Mobile Nodes -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +---------------------------- | |image2| | *Two mobile nodes clustering around a broadcast transmitter* @@ -82,7 +83,7 @@ especially true when taking the half-duplex nature of wireless interfaces running on the same frequency into account, too. C) Point-to-point and Point-to-Multi-Point Links -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +------------------------------------------------ |image3| @@ -100,14 +101,14 @@ tunnel server on the tunnel client side can lead to a congested ADSL upload. Simple Broadcast Avoidances ---------------------------- +=========================== When a node sees just one or no neighbor on a specific interface, then the following, simple rules can be applied to avoid broadcasts on this interface: I.I) No Neighbor -~~~~~~~~~~~~~~~~ +---------------- |image4| @@ -116,7 +117,7 @@ I.I) No Neighbor We can avoid sending a packet into the void. I.II) Single Neighbor: Is Originator -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +------------------------------------ |image5| @@ -128,7 +129,7 @@ I.II) Single Neighbor: Is Originator We can avoid echoing a packet back to the node it originally came from. I.III) Single Neighbor: Is Previous Sender -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +------------------------------------------ |image6| @@ -142,13 +143,13 @@ We can avoid echoing a packet back to the originator node (not just neighor) it was forwarded from. Broadcast Avoidance: Neighborhood Hash --------------------------------------- +====================================== The following approach is supposed to mainly improve scenario A) (while improving scenario B) in some specific cases). Concept -~~~~~~~ +------- - Each node summarizes all neighbors it sees on an interface via one hash. @@ -161,7 +162,7 @@ Concept according neighbor on this interface are avoided. Neighborhood Hash TVLV Format -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +----------------------------- * Packet type: 0x03 (BATADV\_ELP) * TVLV type: 0x01 (BATADV\_TVLV\_NHH) @@ -197,10 +198,10 @@ Neighborhood Hash TVLV Format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Throughput Evaluation -~~~~~~~~~~~~~~~~~~~~~ +--------------------- II.I) Broadcast Packets -^^^^^^^^^^^^^^^^^^^^^^^ +~~~~~~~~~~~~~~~~~~~~~~~ *Ingress Check:* @@ -216,21 +217,20 @@ II.I) Broadcast Packets if fwd-penalty(iface->max_throughput) < neigh->min_throughput: -> no rebroadcast --------------- If either (or both): -| \* The best TX throughput of the neighbor we received the broadcast +* The best TX throughput of the neighbor we received the broadcast packet from with our forwarding penalty applied is smaller than the worst TX throughput of this neighbor (*ingress check*). -| \* Our best TX throughput with our forwarding penalty applied is +* Our best TX throughput with our forwarding penalty applied is smaller than the worst TX throughput of the neighbor we received the broadcast packet from (*egress check*). Then a rebroadcast can be avoided. II.II) OGM2 Packets -^^^^^^^^^^^^^^^^^^^ +~~~~~~~~~~~~~~~~~~~ While for broadcast packets it is desirable to have them travel over the best TX paths, OGMs propagate inversely. That is they travel along the @@ -251,24 +251,22 @@ the process. if fwd-penalty(iface->max_throughput_other) < iface->min_throughput_other: -> no rebroadcast --------------- - If either (or both): -| \* The TX throughput to the neighbor we received the OGM2 packet from +* The TX throughput to the neighbor we received the OGM2 packet from with our forwarding penalty applied is smaller than the worst TX throughput of all our neighbors (*ingress check*). -| \* The best TX throughput of all our neighbors with our forwarding +* The best TX throughput of all our neighbors with our forwarding penalty applied is smaller than the worst TX throughput of all our neighbors (*egress check*). Then a rebroadcast can be avoided. Further readings: -^^^^^^^^^^^^^^^^^ +~~~~~~~~~~~~~~~~~ -\* [[Broadcast-Avoidances-NHH-Assessment\|Broadcast Avoidances - -Neighborhood Hash Assessment]] +* [[Broadcast-Avoidances-NHH-Assessment\|Broadcast Avoidances - + Neighborhood Hash Assessment]] Appendix ======== diff --git a/batman-adv/OGM.rst b/batman-adv/OGM.rst index b8a3da9..0b47b80 100644 --- a/batman-adv/OGM.rst +++ b/batman-adv/OGM.rst @@ -1,3 +1,4 @@ +======================== Originator Message (OGM) ======================== @@ -5,7 +6,7 @@ This page is work-in-progress and will state the BATMAN V algorithm later. 1. Introduction ---------------- +=============== The B.A.T.M.A.N. protocol originally only used a single message type (called OGM) to determine the link qualities to the direct neighbors and @@ -32,7 +33,7 @@ This bears the following advantages from the OGM point of view: - Easier to optimize the OGMs convergence speed. 2. Definitions --------------- +============== - Node - A mesh router which utilizes the B.A.T.M.A.N. protocol as specified in this document on at least one network interface. @@ -73,10 +74,10 @@ is linearly mapped to one byte, 0x00 representing a zero TQ, 0xFF a TQ of one. 3. Conceptual Data Structures ------------------------------ +============================= 3.1. Originator List -~~~~~~~~~~~~~~~~~~~~ +-------------------- An originator list holds all addressable and to a certain degree reachable originators within the mesh network. The Originator Address @@ -91,7 +92,7 @@ actual routing decisions upon incoming data packets. next hop to forward data packets to for the according originator. 3.2 Router List -~~~~~~~~~~~~~~~ +--------------- A router list holds all potential routers, routers that might be switched to at any time without creating a routing loop. An entry @@ -120,10 +121,10 @@ switching to another potential router. related field descriptions) 4. Protocol Procedure ---------------------- +===================== 4.1 Broadcasting own Originator Message (OGM) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +--------------------------------------------- Each node periodically (OGM interval) generates a single OGM which is broadcasted on all hard interfaces. A jitter may be applied to avoid @@ -170,13 +171,13 @@ As well as a possible TT change entry. See [[Client-announcement]] for details. 4.2. Receiving Originator Messages -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +---------------------------------- Upon receiving an OGM a node must perform the following checks before the packet is further processed: 4.2.1. Preliminary Checks -^^^^^^^^^^^^^^^^^^^^^^^^^ +~~~~~~~~~~~~~~~~~~~~~~~~~ - If the OGM contains a version which is different to the own internal version the message must be silently dropped (thus, it must not be @@ -189,7 +190,7 @@ the packet is further processed: silently dropped as this OGM originated from this node. 4.2.2. Potential Router Checks -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following steps check whether the Neighbor we received the OGM from is a potential Router, meaning that we could switch to this Neighbor @@ -247,7 +248,7 @@ A final check then needs to be applied: path TQ values within the OGM flood of one sequence number. 5. Router Ranking -~~~~~~~~~~~~~~~~~ +================= For each OGM having passed the previous checks the according neighbor is a potential, loop-free router. The Router Ranking checks whether just an @@ -270,7 +271,7 @@ step 5.4. For the Router Ranking the following actions must be performed: 5.1. Creating or Updating Originator and Router Entries -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +------------------------------------------------------- In this step we are updating the according entries in the Router list. Step 4.2.2 ensured that the OGM which was not dropped yet is actually @@ -313,7 +314,7 @@ updating and creating process: - Unset the Rebroadcasted flag in this matching router entry. 5.2. Purging Outdated Router Entries -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +------------------------------------ It might happen that for instance from a certain Neighbor we would receive an OGM of perfect quality first and will chose that Router. @@ -368,7 +369,7 @@ more desirable to chose as the new Selected Router than the Router we received this OGM from. 5.3. Switching to (or Keeping) best Router -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +------------------------------------------ This step ensures a good Router selection to the best knowledge of a node. As the Router list only keeps potential, loop-free nodes (due to @@ -392,7 +393,7 @@ Specifically, we must undertake the following actions: - Set the Selected Router's Rebroadcasted flag. 5.4. Purging non-potential Routers -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +---------------------------------- When rebroadcasting a new OGM certain other Routers do not guarantee loop-freeness anymore. We can still chose the Routers from our list that @@ -423,7 +424,7 @@ router list clean-up in this section mandatory to ensure loop-freeness, but the rebroadcasting of an OGM does. 6. Re-broadcasting other nodes' OGMs -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +------------------------------------ When an OGM is to be re-broadcasted some of the message fields must be changed others must be left unchanged. All fields not mentioned in the @@ -436,10 +437,10 @@ following section remain untouched: (after hop penalty) the packet must be dropped. 7. Penalties ------------- +============ 7.1 Hop Penalty -~~~~~~~~~~~~~~~ +--------------- In certain network setups the link quality between neighbors is very similar whereas the number of hops is not. In these scenarios it is @@ -455,19 +456,17 @@ The result always needs to be rounded down to ensure that an outgoing OGM's TQ is always smaller than the incoming OGM's TQ. 8. Proposed Values for Constants --------------------------------- +================================ OGM\_SEQ\_RANGE: 5 TQ\_MAX: 0xFF Appendix --------- - --------------- +======== Questions -========= +--------- - Where to add the description of the data packet forwarding + bonding mode description? Which object should the bonding interface stuff be @@ -475,10 +474,8 @@ Questions - Should the further optimization 'Resend OGMs with flags etc. of newest OGM' already be part of the standard? --------------- - Notes -===== +----- - Section 'Receiving other nodes' OGMs' ensures the loop-freeness - any OGM having past that part and is accepted and loop-safe and can @@ -519,8 +516,6 @@ Notes EIGRP feasible more often. Maybe some potential to optimize things in the 'Router Ranking here later?) --------------- - Changes between OGMs in BATMAN IV and BATMAN V ============================================== @@ -533,14 +528,14 @@ Renaming Removal of Global TQ Window and gl. TQ Averaging ------------------------------------------------ -| Only remember last Path TQ and its sequence number as well as the - highest -| sequence number of an originator node received. The window size is - substituted by a -| SEQ\_DIFF\_MAX (default: 5). A neighbor node is being purged from the - router list -| if orig\_node\ [STRIKEOUT:last\_seqno] router->last\_seqno > - SEQ\_DIFF\_MAX. +Only remember last Path TQ and its sequence number as well as the +highest +sequence number of an originator node received. The window size is +substituted by a +SEQ\_DIFF\_MAX (default: 5). A neighbor node is being purged from the +router list +if orig\_node\ [STRIKEOUT:last\_seqno] router->last\_seqno > +SEQ\_DIFF\_MAX. Removed previous sender field ----------------------------- @@ -551,17 +546,17 @@ Bonding Mode using NDP's link qualities Removal of secondary interface originators ------------------------------------------ -| Instead when receiving an OGM, always the best link quality measured - by NDP -| will be substracted from the OGM. This shall make multiple interfaces -| transparent from the OGM algorithm. +Instead when receiving an OGM, always the best link quality measured +by NDP +will be substracted from the OGM. This shall make multiple interfaces +transparent from the OGM algorithm. Removal of PRIMARIES\_FIRST\_HOP + DIRECTLINK flag -------------------------------------------------- -| PRIMARIES\_FIRST\_HOP flag is no more needed as there will be just one - primary originator a.k. -| originator. +PRIMARIES\_FIRST\_HOP flag is no more needed as there will be just one +primary originator a.k. +originator. Removal of bidirectional link check ----------------------------------- @@ -577,37 +572,37 @@ convergence speed performance. Optimized Route Switching in case of outdated currently selected router ----------------------------------------------------------------------- -| Before in BATMAN IV if a node was receiving an OGM with a sequence - number that caused the -| currently selected router to be moved outside of the global TQ window - (e.g. receiving an -| OGM with an originator's sequence number + 5) the route were switched - to the router this -| OGM just came from. However although the sequence number is very new - and ensures loop-freeness, -| the global TQ via this hop might be very low and therefore this router - being a bad choice. -| As the now newly selected, possibly bad router has the highest - sequence number, it is -| more "difficult" than necessary for another, better neighbor to become - the new router. - -| In BATMAN V, when the sequence number of the currently selected router - becomes too low, -| a node may switch to a different router, a neighbor other then the one - we just received the OGM from: -| It will switch to the router with the highest path TQ which is still - in the OGM\_SEQ\_DIFF\_LIMIT -| and rebroadcast its buffered OGM instead of the just received OGM. The - just received OGM will -| still be buffered (router-addr + seqno + path-TQ) though. +Before in BATMAN IV if a node was receiving an OGM with a sequence +number that caused the +currently selected router to be moved outside of the global TQ window +(e.g. receiving an +OGM with an originator's sequence number + 5) the route were switched +to the router this +OGM just came from. However although the sequence number is very new +and ensures loop-freeness, +the global TQ via this hop might be very low and therefore this router +being a bad choice. +As the now newly selected, possibly bad router has the highest +sequence number, it is +more "difficult" than necessary for another, better neighbor to become +the new router. + +In BATMAN V, when the sequence number of the currently selected router +becomes too low, +a node may switch to a different router, a neighbor other then the one +we just received the OGM from: +It will switch to the router with the highest path TQ which is still +in the OGM\_SEQ\_DIFF\_LIMIT +and rebroadcast its buffered OGM instead of the just received OGM. The +just received OGM will +still be buffered (router-addr + seqno + path-TQ) though. Strict hop-penalty ------------------ -| In BATMAN V the hop penalty always decreases the OGM's path TQ (at - least by 1/255: minimum selectable -| hop penalty: 1, path TQ always rounded downwards) +In BATMAN V the hop penalty always decreases the OGM's path TQ (at +least by 1/255: minimum selectable +hop penalty: 1, path TQ always rounded downwards) Routing loops could potentially occure if a link has 0% packet loss and: @@ -616,19 +611,19 @@ Routing loops could potentially occure if a link has 0% packet loss and: not change the path TQ due to rounding issues?) -| Question: Or is the TTL check in the Router Ranking actually enough? - Anyways, I guess having always -| monotonically decreasing path TQ values of an OGM upon rebroadcasts is - probably also easier to prove -| to be loop-free. And shouldn't harm anything - therefore I'd have a - better feeling with that change. +Question: Or is the TTL check in the Router Ranking actually enough? +Anyways, I guess having always +monotonically decreasing path TQ values of an OGM upon rebroadcasts is +probably also easier to prove +to be loop-free. And shouldn't harm anything - therefore I'd have a +better feeling with that change. Increase NDP window size to 128 packets --------------------------------------- -| With removing the Path TQ averaging, things will get too unstable - otherwise. Should be -| later substituted with an EWMA [1]. +With removing the Path TQ averaging, things will get too unstable +otherwise. Should be +later substituted with an EWMA [1]. -------------- @@ -665,14 +660,14 @@ To be able to reduce the overhead by just putting some intelligent OGM forwarding optimizations in asymmetric neighborhoods -------------------------------------------------------- -| An asymmetric link can either mean that (a) TQ >> RQ or (b) TQ << RQ. -| For OGMs only (b) causes trouble and reduces the propagation time of - an OGM -| and would therefore be the case to optimize. +An asymmetric link can either mean that (a) TQ >> RQ or (b) TQ << RQ. +For OGMs only (b) causes trouble and reduces the propagation time of +an OGM +and would therefore be the case to optimize. -| A node with a neighborhood with asymmetric links as in case (b) can be - further -| devided in the following three cases: +A node with a neighborhood with asymmetric links as in case (b) can be +further +devided in the following three cases: - Church-Tower-Scenario: A node in the valley has symmetric links to most of its close neighbors. @@ -690,12 +685,12 @@ The scenarios could be detected via NDP. Extra OGM Unicasting ~~~~~~~~~~~~~~~~~~~~ -| In the Church-Tower-Scenario extra OGMs could be forwarded via unicast - to the few nodes. -| (Extra OGM broadcasts would be unfair for the other neighbors) +In the Church-Tower-Scenario extra OGMs could be forwarded via unicast +to the few nodes. +(Extra OGM broadcasts would be unfair for the other neighbors) Extra OGM Broadcasting ~~~~~~~~~~~~~~~~~~~~~~ -| For the "Valley"-Scenario an OGM could be broadcasted more than once. -| (Extra OGM Unicasting might result in too many packets) +For the "Valley"-Scenario an OGM could be broadcasted more than once. +(Extra OGM Unicasting might result in too many packets) diff --git a/open-mesh/Gsoc2010-ideas.rst b/open-mesh/Gsoc2010-ideas.rst index c3d2185..cda7595 100644 --- a/open-mesh/Gsoc2010-ideas.rst +++ b/open-mesh/Gsoc2010-ideas.rst @@ -1,3 +1,7 @@ +============== +Gsoc2010 ideas +============== + Requirements for students ========================= diff --git a/open-mesh/New_papers.rst b/open-mesh/New_papers.rst index 531b3b2..a932b52 100644 --- a/open-mesh/New_papers.rst +++ b/open-mesh/New_papers.rst @@ -1,3 +1,7 @@ +========== +New papers +========== + "free" papers ============= diff --git a/open-mesh/WikiStart.rst b/open-mesh/WikiStart.rst index 92694ae..0561290 100644 --- a/open-mesh/WikiStart.rst +++ b/open-mesh/WikiStart.rst @@ -1,3 +1,4 @@ +==================== Welcome to Open Mesh ====================

1 0

[doc] master: doc: Fix warnings about literal section endings (1978214)
by postmaster＠open-mesh.org 13 Jul '17

13 Jul '17

Repository : ssh://git@open-mesh.org/doc On branch : master >--------------------------------------------------------------- commit 19782144e32d5be4eab6ac506e01d1809b6220de Author: Sven Eckelmann <sven(a)narfation.org> Date: Thu Jul 13 21:17:46 2017 +0200 doc: Fix warnings about literal section endings Signed-off-by: Sven Eckelmann <sven(a)narfation.org> >--------------------------------------------------------------- 19782144e32d5be4eab6ac506e01d1809b6220de batman-adv/Broadcast-Avoidances.rst | 27 +-- batman-adv/Faq.rst | 195 +++++++++++---------- batman-adv/Multicast-optimizations-flags.rst | 12 +- .../Multicast-optimizations-listener-reports.rst | 14 +- batman-adv/Multicast-optimizations-tech.rst | 28 +-- batman-adv/Quick-start-guide.rst | 2 - batman-adv/TVLV.rst | 112 ++++++------ batman-adv/Understand-your-batman-adv-network.rst | 111 +----------- 8 files changed, 214 insertions(+), 287 deletions(-) diff --git a/batman-adv/Broadcast-Avoidances.rst b/batman-adv/Broadcast-Avoidances.rst index 3a208a8..5e1c28a 100644 --- a/batman-adv/Broadcast-Avoidances.rst +++ b/batman-adv/Broadcast-Avoidances.rst @@ -163,19 +163,20 @@ Concept Neighborhood Hash TVLV Format ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -| \* Packet type: 0x03 (BATADV\_ELP) -| \* TVLV type: 0x01 (BATADV\_TVLV\_NHH) -| \* Length: 68 bytes -| \* Fixed TVLV fields: -| **** minimum throughput: the worst of all TX throughputs to any - neighbor a node sees on the according interface (4 bytes) -| **** maximum throughput: the best of all TX throughputs to any - neighbor a node sees on the according interface (4 bytes) -| **** neighorhood hash: a sha512 hash summarizing all neighbors a node - sees on the according interface; hash created from neighbor addresses - sorted alphabetically, concatenated, binary (64 bytes) - -\* Definition: +* Packet type: 0x03 (BATADV\_ELP) +* TVLV type: 0x01 (BATADV\_TVLV\_NHH) +* Length: 68 bytes +* Fixed TVLV fields: + + - minimum throughput: the worst of all TX throughputs to any + neighbor a node sees on the according interface (4 bytes) + - maximum throughput: the best of all TX throughputs to any + neighbor a node sees on the according interface (4 bytes) + - neighorhood hash: a sha512 hash summarizing all neighbors a node + sees on the according interface; hash created from neighbor addresses + sorted alphabetically, concatenated, binary (64 bytes) + +* Definition: :: diff --git a/batman-adv/Faq.rst b/batman-adv/Faq.rst index 2bc2b16..412c1d0 100644 --- a/batman-adv/Faq.rst +++ b/batman-adv/Faq.rst @@ -16,22 +16,24 @@ page. B.A.T.M.A.N. General questions ------------------------------ -Does B.A.T.M.A.N. have simulator (NS2, Omnet\ **, etc) support? +Does B.A.T.M.A.N. have simulator (NS2, Omnet, etc) support? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -| **Q:** Does B.A.T.M.A.N. have his own simulator? -| **A:** At this point no, but B.A.T.M.A.N. implementation (we know of) - supports simulators like the ones mentioned above. However, some - people experiment with B.A.T.M.A.N. using emulators (UML/Qemu/etc). If - you are looking for step-by-step instructions to install such a system - you can [[open-mesh:Emulation\|read our emulation document]]. +**Q:** Does B.A.T.M.A.N. have his own simulator? + +**A:** At this point no, but B.A.T.M.A.N. implementation (we know of) +supports simulators like the ones mentioned above. However, some +people experiment with B.A.T.M.A.N. using emulators (UML/Qemu/etc). If +you are looking for step-by-step instructions to install such a system +you can [[open-mesh:Emulation\|read our emulation document]]. How to make my mesh network secure ? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -| **Q:** Can I make my mesh network secure? -| **A:** This depends on the security you want or need. Security is a - big field. Probably you mean encryption and authentication. +**Q:** Can I make my mesh network secure? + +**A:** This depends on the security you want or need. Security is a +big field. Probably you mean encryption and authentication. When you only want to make the whole WLAN stuff unreadable for the outside, you could just use WPA\_NONE or IBSS RSN. But this doesn't @@ -56,12 +58,13 @@ for everything, against any attack and for every purpose" blob. Why does batman need so much time to detect a "dead" node? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -| **Q:** Why can I see a node in the originator table a long time after - it died? *Or:* Does batman really need 200 seconds (PURGE\_TIMEOUT) to - switch the route? -| **A:** Batman switches the route as soon as it learns about a better - path towards a destination which can take a fraction of a second up to - several seconds very much depending on the settings and situation. +**Q:** Why can I see a node in the originator table a long time after +it died? *Or:* Does batman really need 200 seconds (PURGE\_TIMEOUT) to +switch the route? + +**A:** Batman switches the route as soon as it learns about a better +path towards a destination which can take a fraction of a second up to +several seconds very much depending on the settings and situation. When no more new originator messages are sent by a node (because it died), no more routing updates regarding this node are exchanged. Batman @@ -80,48 +83,52 @@ B.A.T.M.A.N. Advanced Questions What can B.A.T.M.A.N. Advanced do? And can't do? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -| **Q:** What offers batman-adv? And what are the 'limitations'? -| **A:** The batman-adv kernel module can only be used to route the - packages within a mesh network, it only simulates OSI layer 2 (data - link layer). It does that as fast as possible and in a smart way. Just - like a switch. +**Q:** What offers batman-adv? And what are the 'limitations'? -| Batman has no security implemented. Also assigning IP addresses to the - node(s) is not Batman's task. -| You may want to use underlying security mechanisms, like: IBSS RSN. +**A:** The batman-adv kernel module can only be used to route the +packages within a mesh network, it only simulates OSI layer 2 (data +link layer). It does that as fast as possible and in a smart way. Just +like a switch. + +Batman has no security implemented. Also assigning IP addresses to the +node(s) is not Batman's task. +You may want to use underlying security mechanisms, like: IBSS RSN. Read more about [[Wiki\|BATMAN]]. Can batman-adv run on interfaces in AP / Station / etc mode ? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -| **Q:** Can BATMAN advanced run on interfaces in AP / Station mode? -| **A:** Yes, because batman-adv doesn't know anything about stuff below - the ethernet interface. So you could also use it over layer 2 ethernet - tunnels, wifi ap, wifi sta, wifi adhoc, ethernet or even write a - virtual interface which prints everything on paper and scans the paper - on the remote machine (but you should be fast or increase the ogm - interval). +**Q:** Can BATMAN advanced run on interfaces in AP / Station mode? + +**A:** Yes, because batman-adv doesn't know anything about stuff below +the ethernet interface. So you could also use it over layer 2 ethernet +tunnels, wifi ap, wifi sta, wifi adhoc, ethernet or even write a +virtual interface which prints everything on paper and scans the paper +on the remote machine (but you should be fast or increase the ogm +interval). How can I connect non-mesh clients to my batman-adv network ? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -| **Q:** How can I connect non-mesh clients to batman-adv network? -| **A:** The [[batman-adv:Quick-start-guide\|batman-adv - quick-start-guide]] explains how to bridge your standard AP / Ethernet - interfaces with bat0 which can be problematic if you only possess one - WiFi card. In these cases it might be desirable to run adhoc mode and - AP mode at the same time. Fortunately, some WiFi chips / drivers - support a so-called "multi VAP" (virtual AP) or "multi SSID" mode to - have multiple WiFi networks on the same WiFi interface. +**Q:** How can I connect non-mesh clients to batman-adv network? + +**A:** The [[batman-adv:Quick-start-guide\|batman-adv +quick-start-guide]] explains how to bridge your standard AP / Ethernet +interfaces with bat0 which can be problematic if you only possess one +WiFi card. In these cases it might be desirable to run adhoc mode and +AP mode at the same time. Fortunately, some WiFi chips / drivers +support a so-called "multi VAP" (virtual AP) or "multi SSID" mode to +have multiple WiFi networks on the same WiFi interface. How big networks does batman-adv support? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -| **Q:** How big networks (maximum nodes) does batman-adv support? -| **A:** That is a good question. It is not possible to give an exact - answer, but there are several parameters limiting the number of nodes - in your network: +**Q:** How big networks (maximum nodes) does batman-adv support? + +**A:** That is a good question. It is not possible to give an exact +answer, but there are several parameters limiting the number of nodes +in your network: #. **Capacity of the wireless network** Usually, the performance of the wireless network renders unusable if @@ -137,11 +144,12 @@ How big networks does batman-adv support? How do I announce IP subnets using batman-adv? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -| **Q:** Can I setup differnt IP subnets using batman-adv? -| **A:** Batman-adv is a OSI layer 2 routing protocol and it does not - handle IP subnets at all. If you want to do IP subnetting, the - suggestion is to split the mesh network in different sub-meshes (e.g. - different ESSID/BSSID), and run a batman-adv instance in each of them. +**Q:** Can I setup differnt IP subnets using batman-adv? + +**A:** Batman-adv is a OSI layer 2 routing protocol and it does not +handle IP subnets at all. If you want to do IP subnetting, the +suggestion is to split the mesh network in different sub-meshes (e.g. +different ESSID/BSSID), and run a batman-adv instance in each of them. |image0| @@ -180,41 +188,47 @@ us if you want to do that. Log file doesn't exists in debugfs? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -| **Q:** The /sys/kernel/debug/batman\_adv/bat0/log file doesn't exists? -| **A:** You need to compile the batman-adv with logging support. +**Q:** The /sys/kernel/debug/batman\_adv/bat0/log file doesn't exists? + +**A:** You need to compile the batman-adv with logging support. -| \* Linux tree -| **** go to **code>Networking support ---> Networking options ---> - B.A.T.M.A.N. Advanced Meshing Protocol** and select - **code>B.A.T.M.A.N. debugging** -| \* external module -| **** compile with make parameter **code>CONFIG\_BATMAN\_ADV\_DEBUG=y** +* Linux tree + + - go to ``Networking support ---> Networking options ---> B.A.T.M.A.N. Advanced Meshing Protocol`` + and select ``B.A.T.M.A.N. debugging`` + +* external module + + - compile with make parameter ``CONFIG_BATMAN_ADV_DEBUG=y`` How to setup B.A.T.M.A.N. so it automatically assign IP addresses? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -| **Q:** How to assign IP addresses automatically? -| **A:** Batman-adv is not responsible for assigning IP addresses. - However, you can use for example a DHCP server. +**Q:** How to assign IP addresses automatically? + +**A:** Batman-adv is not responsible for assigning IP addresses. +However, you can use for example a DHCP server. What about assigning IP addresses in a decentralized way? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -| **Q:** How to assign IP addresses automatically in a decentralized - way? -| **A:** IPv6 will help you to do this easier by using `Unique local - address <https://en.wikipedia.org/wiki/Unique_local_address>`__ (ULA). +**Q:** How to assign IP addresses automatically in a decentralized +way? + +**A:** IPv6 will help you to do this easier by using `Unique local +address <https://en.wikipedia.org/wiki/Unique_local_address>`__ (ULA). What if I want to have a decentralized DNS solution? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -| **Q:** I like to setup a decentralized mesh network and would like to - have a DNS solution. I don't want to use the internet (WWW), but I do - want to have a human readable 'domains' names, just like DNS. What are - the options? -| **A:** Take a look at - `KadNode <https://github.com/mwarning/KadNode>`__. *Note:* This - software is still in beta. +**Q:** I like to setup a decentralized mesh network and would like to +have a DNS solution. I don't want to use the internet (WWW), but I do +want to have a human readable 'domains' names, just like DNS. What are +the options? + +**A:** Take a look at +`KadNode <https://github.com/mwarning/KadNode>`__. *Note:* This +software is still in beta. B.A.T.M.A.N. Advanced - Bridge Loop Avoidance questions ------------------------------------------------------- @@ -222,20 +236,22 @@ B.A.T.M.A.N. Advanced - Bridge Loop Avoidance questions What is Bridge Loop Avoidance? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -| **Q:** What can you do with BLA? -| **A:** Bridge Loop Avoidance is used to detect and avoid loops due to - multiple batX interfaces. [[Bridge-loop-avoidance\|Read more...]] +**Q:** What can you do with BLA? + +**A:** Bridge Loop Avoidance is used to detect and avoid loops due to +multiple batX interfaces. [[Bridge-loop-avoidance\|Read more...]] Why do we need BLA II if we can just use mesh on Ethernet? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -| Under Discussion -> Features you say "no BATMAN packets on the - backbone". -| **Q:** Why would you want to use the mesh (which never has enough - bandwidth anyway) if you have a fast, reliable backbone link between - some of the nodes (eg. LAN)? -| *Or:* Wouldn't it make more sense to get as much done through the - backbone as possible? +Under Discussion -> Features you say "no BATMAN packets on the +backbone". + +**Q:** Why would you want to use the mesh (which never has enough +bandwidth anyway) if you have a fast, reliable backbone link between +some of the nodes (eg. LAN)? +*Or:* Wouldn't it make more sense to get as much done through the +backbone as possible? **A:** You can explicitly use batman-adv on the mesh if you want to - batman-adv allows adding Ethernet interfaces as well. This is a good @@ -261,15 +277,16 @@ supposed to be shared is the users payload traffic. What about DHCP server for separate meshes? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -| **Q:** I would like to setup a DHCP server in separate meshes? *Or:* - How can I make two separate meshes use a single DHCP server (using - gw\_mode feature) in current blaII design? -| **A:** Each node at the edge to the wired network may announce itself - as a gateway, provided that a DHCP server is available in the LAN (or - any network behind it, e.g. a mesh). From a concept view, a gateway - (or maybe even multiple gateways) in mesh2 will not automatically - announced in mesh1 - this must be configured manually, or let batman - use Ethernet if this is explicitly required. +**Q:** I would like to setup a DHCP server in separate meshes? *Or:* +How can I make two separate meshes use a single DHCP server (using +gw\_mode feature) in current blaII design? + +**A:** Each node at the edge to the wired network may announce itself +as a gateway, provided that a DHCP server is available in the LAN (or +any network behind it, e.g. a mesh). From a concept view, a gateway +(or maybe even multiple gateways) in mesh2 will not automatically +announced in mesh1 - this must be configured manually, or let batman +use Ethernet if this is explicitly required. .. |image0| image:: quagga_integration.png diff --git a/batman-adv/Multicast-optimizations-flags.rst b/batman-adv/Multicast-optimizations-flags.rst index f32dc63..874e61a 100644 --- a/batman-adv/Multicast-optimizations-flags.rst +++ b/batman-adv/Multicast-optimizations-flags.rst @@ -122,12 +122,12 @@ cases listed above is present for its bridged segment of the link. If so, it will set one or more of the following multicast flags in its multicast TVLV: -| \* Case !#1: -| **** BATADV\_MCAST\_WANT\_ALL\_UNSNOOPABLES -| \* Case !#2 (no IGMP querier) or Case !#3 (a shadowing IGMP querier) -| **** BATADV\_MCAST\_WANT\_ALL\_IPV4 -| \* Case !#2 (no MLD querier) or Case !#3 (a shadowing MLD querier) -| **** BATADV\_MCAST\_WANT\_ALL\_IPV6 +Case !#1: + BATADV\_MCAST\_WANT\_ALL\_UNSNOOPABLES +Case !#2 (no IGMP querier) or Case !#3 (a shadowing IGMP querier) + BATADV\_MCAST\_WANT\_ALL\_IPV4 +Case !#2 (no MLD querier) or Case !#3 (a shadowing MLD querier) + BATADV\_MCAST\_WANT\_ALL\_IPV6 BATADV\_MCAST\_WANT\_ALL\_UNSNOOPABLES (Bit 0): ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/batman-adv/Multicast-optimizations-listener-reports.rst b/batman-adv/Multicast-optimizations-listener-reports.rst index 4f43f01..734a21c 100644 --- a/batman-adv/Multicast-optimizations-listener-reports.rst +++ b/batman-adv/Multicast-optimizations-listener-reports.rst @@ -67,19 +67,19 @@ batman-adv nodes. *Advantages:* -| \* Simplicity: -| **** No multicast query snooping needed, only multicast report - snooping -| **** No state for querier +* Simplicity: + + - No multicast query snooping needed, only multicast report snooping + - No state for querier *Disadvantages:* -| \* Multicast report overhead for every node (both throughput and +* Multicast report overhead for every node (both throughput and memory) -| \* Might cause issues for switches if more than 4k hosts on the +* Might cause issues for switches if more than 4k hosts on the network: Usually the MAC table of hardware switches only allows up to 4k clients (there are batman-adv networks with 1.5k hosts already). -| \* Central querier(s) +* Central querier(s) (Yet another simple approach to tackle these disadvantages could be through segmenting the IGMP/MLD domain. The OpenWRT-based firmware diff --git a/batman-adv/Multicast-optimizations-tech.rst b/batman-adv/Multicast-optimizations-tech.rst index 30e43d6..a514f0e 100644 --- a/batman-adv/Multicast-optimizations-tech.rst +++ b/batman-adv/Multicast-optimizations-tech.rst @@ -189,26 +189,28 @@ Limitations Next Steps / Roadmap -------------------- -| \* optimization for groups with two or more members: -| **** many-to-some: implement batman-adv multicast packet type - supporting a list of destination addresses (to reduce ICMPv6 overhead - like Neighbor Solicitation Messages, Router Solicitation Messages, MLD - Reports, ...) -| **** some-to-many / streaming: implement path tracking and use these - patches (see [[Multicast-ideas-updated]]) -| \* implement `Multicast Router +* optimization for groups with two or more members: + + - many-to-some: implement batman-adv multicast packet type + supporting a list of destination addresses (to reduce ICMPv6 overhead + like Neighbor Solicitation Messages, Router Solicitation Messages, MLD + Reports, ...) + - some-to-many / streaming: implement path tracking and use these + patches (see [[Multicast-ideas-updated]]) + +* implement `Multicast Router Discovery <https://tools.ietf.org/search/rfc4286>`__ to support scopes greater than link-local, too -| \* implement some faster listener roaming mechanism for bridged in +* implement some faster listener roaming mechanism for bridged in hosts (for instance announce (multicast-address, source address) pairs and use general TT roaming mechanism) -| \* perform multicast listener adition/reduction via TT immediately +* perform multicast listener adition/reduction via TT immediately instead of every OGM interval to reduce join/leave latency in setups with a slow OGM interval -| \* implement source-specific multicast in Linux bridge and batman-adv -| \* multicast TT announcements and forwarding have to be performed per +* implement source-specific multicast in Linux bridge and batman-adv +* multicast TT announcements and forwarding have to be performed per VLAN -| \* ... +* ... Further Readings ---------------- diff --git a/batman-adv/Quick-start-guide.rst b/batman-adv/Quick-start-guide.rst index 79491f1..b07c217 100644 --- a/batman-adv/Quick-start-guide.rst +++ b/batman-adv/Quick-start-guide.rst @@ -151,8 +151,6 @@ through the mesh according to the destination's mac address. For the MTU-part have a look at the note above. -** - Distribution specific examples ------------------------------ diff --git a/batman-adv/TVLV.rst b/batman-adv/TVLV.rst index 05a1c8b..7726b86 100644 --- a/batman-adv/TVLV.rst +++ b/batman-adv/TVLV.rst @@ -137,19 +137,21 @@ TVLV definitions Gateway announcement ~~~~~~~~~~~~~~~~~~~~ -| \* tvlv type: 0x01 -| \* function: Each batman-adv gateway server announces it's available +* tvlv type: 0x01 +* function: Each batman-adv gateway server announces it's available internet connection speed, so that batman-adv gateway clients can select their preferable server. -| \* purpose: Every node keeps a list of batman-adv gateways in the mesh +* purpose: Every node keeps a list of batman-adv gateways in the mesh to later the preferred gateway. -| \* length: 8 byte gateway bandwidth information -| \* Fixed TVLV fields: -| **** gateway bandwidth down: announced gateway download bandwidth in - MBit/s/10 (4Bytes) -| **** gateway bandwidth up: announced gateway upload bandwidth in - MBit/s/10 (4Bytes) -| \* definition: +* length: 8 byte gateway bandwidth information +* Fixed TVLV fields: + + - gateway bandwidth down: announced gateway download bandwidth in + MBit/s/10 (4Bytes) + - gateway bandwidth up: announced gateway upload bandwidth in + MBit/s/10 (4Bytes) + +* definition: :: @@ -204,36 +206,42 @@ Network coding (also known as catwoman) Translation table messages ~~~~~~~~~~~~~~~~~~~~~~~~~~ -| \* tvlv type: 0x04 -| \* function: Local non-mesh clients advertisement mechanism. This +* tvlv type: 0x04 +* function: Local non-mesh clients advertisement mechanism. This particular component needs some parameters that are propagated by the OGM. -| \* purpose: Exchange of translation table state information. -| \* length: variable. It is equal to the size of the fixed TVLV field + +* purpose: Exchange of translation table state information. +* length: variable. It is equal to the size of the fixed TVLV field + the size of the TT VLAN headers + the size of the TT client change entries. -| \* Fixed TVLV fields: -| **** flags: translation table flags (1Byte) -| **** ttvn: translation table version number (1Byte) -| **** num\_vlan: number of TT VLAN data structures inside the tvlv - container (2Bytes) -| \* Each TT VLAN data structure contains: -| **** crc: crc32 checksum of the local translation (sub-)table - containing entries belonging to this VLAN only (4Bytes) -| **** vid: the identifier of this VLAN (2Bytes) -| **** reserved: not used. Defined for alignment purposes (2Bytes) -| \* Each TT client change (one per announced client) contains: -| **** flags: flags associated with this client -| **** reserved: not used. Defined for alignment purposes (3Bytes) -| **** addr: mac address of the announced client -| **** vid: identifier of the VLAN where this client is connected to -| \* layout: +* Fixed TVLV fields: + + - flags: translation table flags (1Byte) + - ttvn: translation table version number (1Byte) + - num\_vlan: number of TT VLAN data structures inside the tvlv + container (2Bytes) + +* Each TT VLAN data structure contains: + + - crc: crc32 checksum of the local translation (sub-)table + containing entries belonging to this VLAN only (4Bytes) + - vid: the identifier of this VLAN (2Bytes) + - reserved: not used. Defined for alignment purposes (2Bytes) + +* Each TT client change (one per announced client) contains: + + - flags: flags associated with this client + - reserved: not used. Defined for alignment purposes (3Bytes) + - addr: mac address of the announced client + - vid: identifier of the VLAN where this client is connected to + +* layout: :: .... -\* definition: +* definition: :: @@ -282,18 +290,19 @@ Translation table messages Roaming Advertisement message ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -| \* tvlv type: 0x05 -| \* function: Reduce a non-mesh client's packet loss when it roams from +* tvlv type: 0x05 +* function: Reduce a non-mesh client's packet loss when it roams from one AP to the next. -| \* purpose: Inform the old AP about the new location of the non-mesh +* purpose: Inform the old AP about the new location of the non-mesh client. -| \* length: 8 bytes non-mesh client information -| \* Fixed TVLV fields: -| **** client mac address: mac address of the roaming non-mesh client (6 - bytes) -| **** vid: vlan tag id of the roaming non-mesh client (2 bytes) +* length: 8 bytes non-mesh client information +* Fixed TVLV fields: -\* definition: + - client mac address: mac address of the roaming non-mesh client (6 + bytes) + - vid: vlan tag id of the roaming non-mesh client (2 bytes) + +* definition: :: @@ -310,22 +319,23 @@ Roaming Advertisement message Multicast capability ~~~~~~~~~~~~~~~~~~~~ -| \* tvlv type: 0x06 -| \* function: Reduces the airtime consumed by multicast packets, e.g. +* tvlv type: 0x06 +* function: Reduces the airtime consumed by multicast packets, e.g. by using multicast awareness to decide whether a frame can be sent via unicast or dropped. -| \* purpose: Lets other nodes know whether an originator is capable of +* purpose: Lets other nodes know whether an originator is capable of announcing its multicast listeners via the translation table. The flags further inform other nodes about whether an originator needs to receive all multicast traffic of a certain type. -| \* length: 4 bytes (1 byte flag information) -| \* Fixed TVLV fields: -| **** flags: multicast flags announced by the orig node (1 byte), see - [[Multicast-optimizations-flags\|the multicast flags page]] for - details -| **** reserved: not used. Defined for alignment purposes (3 bytes) - -\* definition: +* length: 4 bytes (1 byte flag information) +* Fixed TVLV fields: + + - flags: multicast flags announced by the orig node (1 byte), see + [[Multicast-optimizations-flags\|the multicast flags page]] for + details + - reserved: not used. Defined for alignment purposes (3 bytes) + +* definition: :: diff --git a/batman-adv/Understand-your-batman-adv-network.rst b/batman-adv/Understand-your-batman-adv-network.rst index 937161b..024af6b 100644 --- a/batman-adv/Understand-your-batman-adv-network.rst +++ b/batman-adv/Understand-your-batman-adv-network.rst @@ -35,14 +35,6 @@ neighbor table :: - - - - -Sample output: - -:: - cat /sys/kernel/debug/batman_adv/bat0/neighbors [B.A.T.M.A.N. adv d5e8ba8, MainIF/MAC: eth0/fe:fe:00:00:01:01 (bat0 BATMAN_IV)] IF Neighbor last-seen @@ -52,15 +44,6 @@ Sample output: :: - - - - - -Sample output: - -:: - cat /sys/kernel/debug/batman_adv/bat0/neighbors [B.A.T.M.A.N. adv 2016.1, MainIF/MAC: eth0/fe:fe:00:00:01:01 (bat1 BATMAN_V)] Neighbor last-seen ( throughput) [ IF] @@ -82,17 +65,6 @@ line contains information regarding a specific originator: :: - - - - - - - -Sample output: - -:: - cat /sys/kernel/debug/batman_adv/bat0/originators [B.A.T.M.A.N. adv d5e8ba8, MainIF/MAC: eth0/fe:fe:00:00:01:01 (bat0 BATMAN_IV)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... @@ -102,17 +74,6 @@ Sample output: :: - - - - - - - -Sample output: - -:: - cat /sys/kernel/debug/batman_adv/bat0/originators [B.A.T.M.A.N. adv 2016.1, MainIF/MAC: eth1/fe:fe:00:00:01:01 (bat0 BATMAN_V)] Originator last-seen ( throughput) Nexthop [outgoingIF]: Potential nexthops ... @@ -146,16 +107,6 @@ be found in the transtable\_local file: :: - - - - - - -Sample output: - -:: - cat /sys/kernel/debug/batman_adv/bat0/transtable_local Locally retrieved addresses (from bat0) announced via TT (TTVN: 2): Client VID Flags Last seen (CRC ) @@ -186,18 +137,6 @@ can be found in the transtable\_global file: :: - - - - - - - - -Sample output: - -:: - cat /sys/kernel/debug/batman_adv/bat0/transtable_global Globally announced TT entries received via the mesh bat0 Client VID (TTVN) Originator (Curr TTVN) (CRC ) Flags @@ -233,17 +172,6 @@ this feature). Each line contains information about a specific gateway: :: - - - - - - - -For example: - -:: - Gateway (#/255) Nexthop [outgoingIF]: advertised uplink bandwidth ... [B.A.T.M.A.N. adv 2014.0.0, MainIF/MAC: eth0/fe:fe:00:00:01:01 (bat0)] fe:fe:00:00:01:01 (233) fe:fe:00:00:01:01 [ eth0]: 2.0/0.5 MBit => fe:fe:00:00:02:01 (255) fe:fe:00:00:02:01 [ eth0]: 10.0/2.0 MBit @@ -256,18 +184,10 @@ avoidance]] code and contains all claimed clients as announced on the bridge. Each line contains a claimed non-mesh client propagated through the mesh: -:: - - - - - - - Note: -| \* Clients claimed by the node itself are marked with an '[x]'. -| \* If no VLAN was found a VID of '-1' is printed. +* Clients claimed by the node itself are marked with an '[x]'. +* If no VLAN was found a VID of '-1' is printed. :: @@ -285,20 +205,12 @@ avoidance]] code and contains all backbone gateways. Each line contains a backbone gateway which is reachable via LAN and mesh (that means, it is in the same bla group): -:: - - - - - - - Note: -| \* the own originator address is not printed, only other backbone +* the own originator address is not printed, only other backbone gateways -| \* If no VLAN was found a VID of '-1' is printed. -| \* the last seen time should be between 0 and 10 seconds if there is +* If no VLAN was found a VID of '-1' is printed. +* the last seen time should be between 0 and 10 seconds if there is no packet lost :: @@ -323,13 +235,6 @@ Distributed ARP Table - local cache table which the node is in charge to handle in the [[DistributedARPTable-technical\|DHT]] -:: - - - - - - For example: :: @@ -355,12 +260,6 @@ NC code to search for potential coding opportunities, where a relay determines if two receivers are likely to be able to decode a network coded transmission. -:: - - - - - This example shows the entry for the one-hop originator with address fe:fe:00:00:02:01. Since a originator can always overhear packets to and from itself, its own address is listed as the first. In this case, the

1 0

[doc] master: doc: Fix warning about missing title for "Wbmv4-batmandev-agenda" (25936a4)
by postmaster＠open-mesh.org 13 Jul '17

13 Jul '17

Repository : ssh://git@open-mesh.org/doc On branch : master >--------------------------------------------------------------- commit 25936a42c47bd85c40d6097850b91781317fe157 Author: Sven Eckelmann <sven(a)narfation.org> Date: Thu Jul 13 20:50:24 2017 +0200 doc: Fix warning about missing title for "Wbmv4-batmandev-agenda" Signed-off-by: Sven Eckelmann <sven(a)narfation.org> >--------------------------------------------------------------- 25936a42c47bd85c40d6097850b91781317fe157 open-mesh/Wbmv4-batmandev-agenda.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/open-mesh/Wbmv4-batmandev-agenda.rst b/open-mesh/Wbmv4-batmandev-agenda.rst index b057234..cebac7b 100644 --- a/open-mesh/Wbmv4-batmandev-agenda.rst +++ b/open-mesh/Wbmv4-batmandev-agenda.rst @@ -1,4 +1,5 @@ -= Wireless Battle Mesh v4 - Developer Meeting Agenda = +Wireless Battle Mesh v4 - Developer Meeting Agenda +================================================== | Party!!! | Celebrate batman-adv 2.6.38 Linux kernel integration

1 0

[doc] master: doc: Remove testlog only pages (e05d49d)
by postmaster＠open-mesh.org 13 Jul '17

13 Jul '17

Repository : ssh://git@open-mesh.org/doc On branch : master >--------------------------------------------------------------- commit e05d49d50c0a15197008b7d6d24e533cb21a0602 Author: Sven Eckelmann <sven(a)narfation.org> Date: Thu Jul 13 20:46:24 2017 +0200 doc: Remove testlog only pages Signed-off-by: Sven Eckelmann <sven(a)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

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commits July 2017