[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 "

["Ligang LIU" <heishuihe2008@163.com>]

Hi, dear all,

Thanks a lot to clarify my questions.

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.

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.

I hope my tests can be helpful to improve the batman-adv V and your comments and suggestions are appreciated.

Here are the test results, for your reference, where the performance of V without mcast_rate setting is not provided because it is almost not acceptable. It can be also found that IV performs better over V and I will do more tests, following the suggestions in your previous emails, to improve the performance of V.

delay(ms)	
To (IV with mcast)	(IV without mcast)	(V with mcast)
n1	1.508 	4.852 	10.069 
n2	0.563 	3.435 	17.041 
n3	2.183 	29.350 	25.851 
n5	1.885 	2.428 	18.071 
n6	1.193 	5.852 	73.519 
n7	0.547 	2.314 	2.504 

throughput(Mbps)
To (IV with mcast)	(IV without mcast)	(V with mcast)
n1	7.650 	4.740 	2.770 
n2	7.750 	8.460 	2.640 
n3	1.200 	0.372 	0.000 
n5	8.630 	6.960 	4.420 
n6	2.830 	5.770 	0.578 
n7	25.000 	21.600 	16.900 

Yours Sincerely
Ligang


At 2018-08-31 18:30:00, "Sven Eckelmann" <sven@narfation.org> wrote:
>On Freitag, 31. August 2018 17:52:39 CEST Ligang LIU wrote:
>> 1. many unicast packets, with length of 200 bytes. I guess it's ELP unicast.
>> 2. some batman-adv broadcast packets of 56 bytes length. I guess it's OGM2?
>> 3. several batman-adv broadcast packets of 16 bytes length. It's ???
>
>First two are correct and the the 16 bytes one is the broadcast ELP. I 
>personally have no idea at the moment why the requested padding [0] was not 
>implemented.
>
>Especially because this frame will now be dropped over some interfaces. We 
>already saw this in the past with fragmented frames [1]. You can increase the 
>size in batadv_v_elp_iface_enable by adding the number x to the alloc and the 
>skb_put. For example 44 to get to the minimum ethernet frame size:
>
>    hard_iface->bat_v.elp_skb = dev_alloc_skb(size + 44);
>    ...
>    elp_buff = skb_put_zero(hard_iface->bat_v.elp_skb, BATADV_ELP_HLEN + 44);
>
>
>> 3. many rts/cts/ack packets.
>
>Is it possible that RTS, CTS + unicast retries take most of the airtime in 
>your setup?
>
>
>> I noticed 2 macro definitons.
>> #define BATADV_ELP_PROBES_PER_NODE 2
>> #define BATADV_ELP_MIN_PROBE_SIZE 200 /* bytes */
>> I wonder why it sends 2 prob ELP packets to each neighbour.
>> Can I change the value of BATADV_ELP_PROBES_PER_NODE from 2 to 1?
>> And can I decrease ELP prob packet size from 200 to 100, in order to decrase the ELP airtime?
>
>@Antonio, @Marek: Maybe you can explain it better than me.
>
>I would guess that Antonio wanted to make sure that the rate control algorithm 
>of the driver probes enough and thus provides a more realistic expected 
>throughput.
>
>But I would guess that the size doesn't matter much. It is more likely that 
>all the stuff around the actual data frame (rts, cts, IFS, ...) takes more 
>airtime.
>
>
>And you can just use elp_interval [2] to reduce the number of times broadcast 
>and unicast ELP frames are transmitted. But yes, reducing the number of probes 
>per node might also be interesting. There is also BATADV_ELP_PROBE_MAX_TX_DIFF 
>to reduce the time even further - but according to a comment [3], this may
>make problems with minstrel. But I am not really sure about that because the
>default elp_interval (500ms) is also already larger than 100ms.
>
>Kind regards,
>	Sven
>
>[0] https://www.open-mesh.org/projects/batman-adv/wiki/ELP#section-9
>[1] https://git.open-mesh.org/batman-adv.git/commit/11a0c90b439190fd6a104caac5d4ef09e1f65a96
>[2] https://www.open-mesh.org/projects/batman-adv/wiki/Tweaking#ELP-interval
>[3] https://git.open-mesh.org/batman-adv.git/blob/89dcbd5f2373b955fc8eabb909f6188ae33110b7:/net/batman-adv/bat_v_elp.c#l218