Open-Mesh » batman-adv

Please read: Multi-link-optimize

I've already read your documentation. Using multiple interfaces on different channels or multiple bands is completely different to this approach where one interface is used with a channel hopping algorithm to maximize the bandwidth without breaking the mesh because using different channels.

Could you summarize the workings of that algorithm ? How does channel hopping increase performance ?

Ruben Kelevra wrote:

Well, I does not know exactly how this algorithm works, but it have a jump patter and a synchronization between the nodes. So the nodes exchange data when they are on the same channel, buffering the data which goes to nodes which are currently not available.

With different flows thru a mesh-network, the different flows are spread to the airtime of independent channels. The maximum throughput of the mesh is increased.

Well, I also don't know how the algorithm works. If you don't know why do you ask if we can implement it ? Shouldn't you at least make the effort trying to understand what you are advocating ? Before time is spent on implementation and debugging we have to understand if the whole endeavor is worthwhile.

Right now, it feels like you are throwing a random paper with a nice looking graph at us while asking us to do all the work (reading, understanding the algorithm, understanding whether it makes sense, implementation, testing & debugging). What is your part in all this ?

I'm sorry for saying this, but your initiated discussion is strange for me.

My goal was not to learn C and implement it for myself, in this case I would send you a patch.

The intentions for my ticket were:

-have you ever heard of this paper/algorithm?
-might it be compatible to batman-adv's routing-approach?
-would you think a possible implementation is worth the benefit?

If the team behind batman-adv can answer the last two with yes or 'might be', the team should ask the authors of the paper if there algorithm is free. Or if they want to make it free for the use in batman-adv.

Best regards

Ruben

Ruben Kelevra wrote:

My goal was not to learn C and implement it for myself, in this case I would send you a patch.

When did I ask for a patch implementing this feature ? If you look closely, you will find that I asked what exactly you are proposing (how does the algorithm work). No C knowledge is necessary to do so.

-have you ever heard of this paper/algorithm?

I believe to have answered this questions already. I don't know how the algorithm works and have never heard of it.

-might it be compatible to batman-adv's routing-approach?

Unknown as long as we don't know what the algorithm actually does.

-would you think a possible implementation is worth the benefit?

Unknown as long as we don't know what the algorithm actually does.

If the team behind batman-adv can answer the last two with yes or 'might be', the team should ask the authors of the paper if there algorithm is free. Or if they want to make it free for the use in batman-adv.

The team batman-adv can only give you the same answer as before: Nobody has heard of this algorithm and nobody knows how it works. Before time is spent on implementation and debugging we have to understand if the whole endeavor is worthwhile.

Hi Ruben,

the issue tracker is not really that useful for tracking rough ideas. Better use the mailinglist and IRC first. There other people can acknowledge or discard ideas, too and its not limited to the busy devs there. And at least try to pretend that you tried to do some "homework" yourself ;) (not ment in a too harsh way :P).

Cheers, Linus

Actually this is still a feature request which I've like to be solved. Please reopen.

Please read the closing message again:

Antonio Quartulli wrote:

Let's discuss on the mailing list if required.

Here are some rather old (and sketchy) notes I made at that time:

• requires IEEE 802.11 phy+link layer control
• requires access to the IEEE 802.11 headers (to insert and read information)
• requires flow control on IEEE 802.11 layer
• requires buffering on IEEE 802.11 layer and new resubmission strategies
• requires long IEEE 802.11 control format
• conflicts with the BATMAN IV TQ value due to channel switches (and thus loss of broadcast messages)
• increases reaction time of BATMAN IV/V
• number of ortogonal channels is a lot less when using modern (now commonly used) channel widths (40, 80, 160)
• most likely interferes with DFS detection on all cards - so the DFS channels cannot be used
• switching time of 80 us sounds too short for modern cards with wifi firmware and switching quirks which are not limited only by the VCO/PLL (but haven't tested it
  - so maybe they are still correct about that)
  - should be discussed with the channel switch developers
• required in their simulation to disable aggregation+hw buffering (only queue 1 packet) to keep in full control over transmission
• algorithm is meant for long flows (short transmissions seem to be a problem regarding latency and initial common transmission slot before total synchronization happens)

If this really is interesting for today's setups then batman-adv doesn't seem to the correct place to implement it.