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 "
On Dienstag, 4. September 2018 17:07:34 CEST Ligang LIU wrote: [...]
I captured frames with tcpdump and found somethings.
[..]
The pcap files are attached in this email. I'm not sure whether it's proper to send them to the mailinglist, so I don't cc this email to the mailinglist.
The mails would have been held back and I might not have accepted them due to the size of the attachments. So you did everything right.
I have now added the mailing list again to the Cc
First, there are many ELP unicast packets.
Second, there are many RTS/CTS/ACK. When a node wants to send ELP unicast packets to a weak neighbor, this will happen frequently. While in batman-adv 4, there is only a very small amount of RTS/CTS frames.
Ack
Third, change elp interval from 500 to 1000 will decrease ELP unicast packets but it does not decrease RTS/CTS too much.
Shouldn't the number of probes be reduced and thus also the RTS? It is something which the wifi layer handles - not batman-adv.
And the duration of the RTS frames seem to be rather high (I don't say that these are wrong) when I've looked through the dump via
(wlan.fc.type_subtype == 0x001b) || ((llc.type == 0x4305) && (data.data[0] == 03))
Maybe someone can check whether they make sense or not (don't have the time right now to do it).
Although Antonio explained in the previous email, "... if you have no data over the link, sending 2 probes of 200bytes each every 500ms (default ELP interval) won't really eat much airtime, unless you have a lot of idling 1-hop neighbours", I think the ELP probe packets will occupy much wifi airtime, because wlan is working on the SHARED media. The transmission of ELP probe packets between idle 1-hop neighbours can be heard by the other nodes and their transmission have to be delayed. Consequently, the performance, delay and throughput, could be lowered down, compared to batman-adv 4.
@Antonio, you must also keep in mind that the RTS + CTS frames are transmitted at the lowest available rate (1Mbit/s in this case). The Ack is done with 6Mbit/s in his dump. The broadcast is done with 18Mbit/s. The unicast stuff seems to be send with MCS rates.
The RTS+CTS will therefore use an amazing high number of airtime (but I didn't do the calculations). Attached are some estimates using Dave Taht's airtime- pie-chart fork [1] + a modification to show the transmitter and not the destination host. And these numbers are the raw ones - not normalized in any way (so not directly comparable). Don't forget that these also don't take the duration field of the RTS into account.
[...]
And, my wireshrk (windows, v2.6.3) can not analize the batman-adv 5 packet. I find a wireshark code for batman-adv: https://github.com/wireshark/wireshark/blob/master/epan/dissectors/packet-ba... Is it for batman-adv 4 only? Do you know any plugin to do this?
It only support B.A.T.M.A.N. IV frames of different version. Feel free to submit the ELP and OGM2 support to wireshark (this is not necessarily directed to Ligang but to everyone).
Kind regards, Sven
On Dienstag, 4. September 2018 12:34:35 CEST Sven Eckelmann wrote: [...]
Although Antonio explained in the previous email, "... if you have no data over the link, sending 2 probes of 200bytes each every 500ms (default ELP interval) won't really eat much airtime, unless you have a lot of idling 1-hop neighbours", I think the ELP probe packets will occupy much wifi airtime, because wlan is working on the SHARED media. The transmission of ELP probe packets between idle 1-hop neighbours can be heard by the other nodes and their transmission have to be delayed. Consequently, the performance, delay and throughput, could be lowered down, compared to batman-adv 4.
@Antonio, you must also keep in mind that the RTS + CTS frames are transmitted at the lowest available rate (1Mbit/s in this case). The Ack is done with 6Mbit/s in his dump. The broadcast is done with 18Mbit/s. The unicast stuff seems to be send with MCS rates.
[...]
Maybe Marek is also interested in disabling the RTS for fallback rates on all devices. The rts stuff is injected by minstrel_ht and can most likely be disabled using:
--- a/net/mac80211/rc80211_minstrel_ht.c +++ b/net/mac80211/rc80211_minstrel_ht.c @@ -853,12 +853,12 @@ minstrel_ht_set_rate(struct minstrel_priv *mp, struct minstrel_ht_sta *mi, * - if station is in dynamic SMPS (and streams > 1) * - for fallback rates, to increase chances of getting through */ - if (offset > 0 || + /* if (offset > 0 || (mi->sta->smps_mode == IEEE80211_SMPS_DYNAMIC && group->streams > 1)) { ratetbl->rate[offset].count = ratetbl->rate[offset].count_rts; flags |= IEEE80211_TX_RC_USE_RTS_CTS; - } + }*/
ratetbl->rate[offset].idx = idx; ratetbl->rate[offset].flags = flags;
(I hope this is ported correctly - his original patch was for an older version and thus looked slightly different)
What also could be interesting, would be to change consistently the 802.1d priority (0-7) of the ELP probe packets on each device from 0 to something else. This could for example be done with:
--- a/net/batman-adv/bat_v_elp.c +++ b/net/batman-adv/bat_v_elp.c @@ -230,6 +230,8 @@ batadv_v_elp_wifi_neigh_probe(struct batadv_hardif_neigh_node *neigh) BATADV_ELP_MIN_PROBE_SIZE);
for (i = 0; i < BATADV_ELP_PROBES_PER_NODE; i++) { + u8 prio_802_1d = 0; + elp_skb_len = hard_iface->bat_v.elp_skb->len; skb = skb_copy_expand(hard_iface->bat_v.elp_skb, 0, probe_len - elp_skb_len, @@ -242,6 +244,7 @@ batadv_v_elp_wifi_neigh_probe(struct batadv_hardif_neigh_node *neigh) * throughput estimation effective. */ skb_put_zero(skb, probe_len - hard_iface->bat_v.elp_skb->len); + skb->priority = 256 + prio_802_1d;
batadv_dbg(BATADV_DBG_BATMAN, bat_priv, "Sending unicast (probe) ELP packet on interface %s to %pM\n",
The TID in the QoS packets should change accordingly.
The default mapping for these prio_802_1d values can be found in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/net/ma...
Kind regards, Sven
b.a.t.m.a.n@lists.open-mesh.org
-
Sven Eckelmann