public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
From: Sven Eckelmann <sven@narfation.org>
To: Ligang LIU <heishuihe2008@163.com>
Cc: The list for a Better Approach To Mobile Ad-hoc Networking
	<b.a.t.m.a.n@lists.open-mesh.org>,
	a@unstable.cc, mareklindner@neomailbox.ch
Subject: Re: [B.A.T.M.A.N.] mcast_rate setting of wifi interface has significant effect to performance of V. Re:Re: Recent test result. Re:Re: Paper "Performance Evaluation of BATMAN-adv Wireless Mesh Network Routing Algorithms "
Date: Mon, 03 Sep 2018 08:25:05 +0200	[thread overview]
Message-ID: <3183122.uSX0CgPaFQ@bentobox> (raw)
In-Reply-To: <2246411.730f.1659d99341d.Coremail.heishuihe2008@163.com>

[-- Attachment #1: Type: text/plain, Size: 2428 bytes --]

On Montag, 3. September 2018 12:03:07 CEST Ligang LIU wrote:
[...]
> I'm continuing to test in my deployment and has found an interesting thing:
> The mcast_rate setting of wifi interface has significent effect to performance of V,
> while it does not affect batman-adv IV too much.
> 
> config wifi-iface 'default_radio1'
>         option mcast_rate '18000'
>         ......
> 
> I generated the wireless configuration in web page and there is no mcast_rate setting for adhoc mode. When I noticed the line "option mcast_rate '18000'" in the batman-adv wiki page, I tried to set mcast_rate and repeated the test. I find that, with mcast_rate setting, batman-adv IV will get some performance improvement, and the performance of batman-adv V has significantly improved.

Still sounds like something is eating away airtime. Just changing the 
multicast rate here will just make more room for other frames since the 
multicast/broadcast packets take less time to get transmitted. There are other 
effects on the amount of multicast/broadcast packets which will be lost 
(interesting for B.A.T.M.A.N. IV) but I would guess that we can ignore that at 
the moment.


Did you investigate what is the problem here? Did you play around with the ELP 
interval? Did you check the RTS/CTS durations? Did you find anything else 
which eats too much airtime when you compare B.A.T.M.A.N. IV and B.A.T.M.A.N. 
V? Is the higher ELP broadcast interval (compared to B.A.T.M.A.N IV OGM 
interval) to blame here or the ELP unicast probes?

> I'm now trying to understand how the mcast_rate affects the performance of the adhoc network. If more tests can verify the importance of this setting, I so suggest that it should be highlighted for the end users of the batman-adv, especially for the new ones. For the OpenWRT system, if mcast_rate can be automatically set for the adhoc mode, or the related web page can explicitly provide a user interface  to set mcast_rate in adhoc mode, it should be more end user friendly.

Please get in touch with the OpenWrt LuCI developers [1] about the OpenWrt 
"webpage" configuration. We cannot really help you here.
 
> I hope my tests can be helpful to improve the batman-adv V and your comments and suggestions are appreciated.

Since it is not clear at the moment why it happens, we cannot do anything on 
our end.

Kind regards,
	Sven

[1] https://github.com/openwrt/luci/
    http://luci.subsignal.org/trac

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2018-09-03  6:25 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-04 11:38 [B.A.T.M.A.N.] Paper "Performance Evaluation of BATMAN-adv Wireless Mesh Network Routing Algorithms " Sven Eckelmann
2018-08-04 14:39 ` jmh8
2018-08-04 15:34   ` Sven Eckelmann
2018-08-11  6:47     ` jmh8
     [not found] ` <2018081310240755548768@mail.sim.ac.cn>
2018-08-13  7:40   ` Sven Eckelmann
2018-08-30  7:50     ` [B.A.T.M.A.N.] Recent test result. " Ligang LIU
2018-08-30  8:17       ` Sven Eckelmann
2018-08-30  8:55         ` Ligang LIU
2018-08-30  9:06           ` Sven Eckelmann
2018-08-31  9:52             ` Ligang LIU
2018-08-31 10:30               ` Sven Eckelmann
2018-08-31 10:41                 ` Sven Eckelmann
2018-08-31 12:16                 ` Marek Lindner
2018-09-01  9:33                   ` Antonio Quartulli
2018-09-01  9:08                 ` Sven Eckelmann
2018-09-03  4:03                 ` [B.A.T.M.A.N.] mcast_rate setting of wifi interface has significant effect to performance of V. " Ligang LIU
2018-09-03  6:25                   ` Sven Eckelmann [this message]
     [not found]                     ` <aa797db.cdf1.165a3d64b19.Coremail.heishuihe2008@163.com>
2018-09-04 10:34                       ` Sven Eckelmann
2018-09-05 17:40                         ` Sven Eckelmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3183122.uSX0CgPaFQ@bentobox \
    --to=sven@narfation.org \
    --cc=a@unstable.cc \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    --cc=heishuihe2008@163.com \
    --cc=mareklindner@neomailbox.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox