Bug #416

B.A.T.M.A.N. V: include packet loss in link throughput estimation

Added by Antonio Quartulli 30 days ago. Updated 29 days ago.

batman-adv developers
Target version:
Start date:
Due date:
% Done:


Estimated time:


I have 2 dual radio APs (1 x 2.4GHz and 1 x 5GHz, both ath10k).
The APs are placed in two different rooms with various walls in between. Because of that meshing over 5GHz is quite unreliable.

Batman-adv is often selecting the route going over the 5GHz radio because the tx rate (used to estimate the throughput) is often higher.
This route selection, however, turns out to be a very bad choice because the packet loss makes the 5GHz link unusable (I can hardly ping the other AP with batctl p).

(I wonder though, why is the tx rate often this high if packet loss is high as well...?)

One way to mitigate this issue would be to include the packet loss in the 1-hop link throughput estimation logic.
Mixing throughput and packet loss can be quite complicated, therefore I would like to keep it simple: i.e. when packet loss over a link is below 50%, drop the throughput to 0.1Mbps.
This way that link is heavily penalized and excluded from the routing (unless it's the only choice we have).

To measure the 1-hop packet loss we could either use the OGMs (similarly to what we did in B.A.T.M.A.N. IV, but it may become ugly quite fast) or we could rely on counting the received ELPs and sending back a periodic report to the sender.

Opinions? Comments?



Updated by Antonio Quartulli 30 days ago

  • Description updated (diff)

Updated by Antonio Quartulli 30 days ago

  • Description updated (diff)

Updated by Simon Wunderlich 30 days ago

Shouldn't we discuss this on the mailing list? :)

But anyway: Did you check where the throughput estimation comes from? It could be that only the selected modulation is reported, and not an actual throughput estimate based on modulation + success rate (like we get from minstrel with ath9k).

If we have the choice between ELP and OGM to implement this extension, I think ELP is the better place since this is really about the link.


Updated by Sven Eckelmann 30 days ago

Yes, the throughput is not actually the expected throughput for ath10k but the modulation rate. It is a "regression" caused by this commit:


Updated by Linus L├╝ssing 29 days ago

It seems, from skimming the 802.11s code, that 802.11s is able to do a more reliable, driver independent throughput estimation here:

So via checking the "(struct ieee80211_tx_info *)txinfo->flags & IEEE80211_TX_STAT_ACK flag" and "&sta->tx_stats.last_rate". And the result should then be stored in "&sta->mesh->tx_rate_avg".

Maybe that's a more reliable source for us as well, especially for ath10k?

Also available in: Atom PDF