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:
- many unicast packets, with length of 200 bytes. I guess it's ELP unicast.
- some batman-adv broadcast packets of 56 bytes length. I guess it's OGM2?
- 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);
- 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/11a0c90b439190fd6a104caac5d4... [2] https://www.open-mesh.org/projects/batman-adv/wiki/Tweaking#ELP-interval [3] https://git.open-mesh.org/batman-adv.git/blob/89dcbd5f2373b955fc8eabb909f618...