Hi,

please don't contact me privately about batman-adv (unless you have a really, really, really, really good reason for that and explain the reason for that in the mail). At least Cc the official mailing list b.a.t.m.a.n@lists.open-mesh.org

On Dienstag, 14. August 2018 05:32:48 CEST heishuihe2008@163.com wrote: [...]

I'm the author of paper "Performance Evaluation of BATMAN-adv Wireless Mesh Network Routing Algorithms". Thank you very much for your comments on our work.

I am sorry for some wrong statements in the discussed paper. Actually I'm new in OpenWRT/LEDE development and have much misunderstanding on it.

The problem is now that the paper with the wrong statements, graphs and conclusions is now published by IEEE. Thus my proposal to retract it and prepare a new paper which doesn't contain the flaws.

[...]

The following is the email I tried to send before. Just for reference.

I'll continue to work on the batman-adv algorithms and report our result to the community.

[...]

发件人： heishuihe2008@163.com 发送时间： 2018-03-22 16:29 收件人： b.a.t.m.a.n 主题： What's the exact definition of expected_throughput in BATMAN-ADV V? Dear all,

I'm working on a wireless mesh network based on 802.11.

When I tried to test the BATMAN-ADV V, I got very poor performance compared to version IV.

I guessed the reason was V had much more management costs than IV.

As we now know - most likely not the main contributor. But we will only know it when proper tests have been done.

Recently I found that the throughput metric was not reliable, probably. The expected_throughput value from cfg80211_get_station is different from the one with batctl tp. Which one is the correct?

Depends on what you actually consider correct. cfg80211_get_station should provide a similar value as `batctl tp` for single hop tests with only a single possible link. The first one is done by the driver (actually the rate control minstrel in many cases) and is hopefully correctly implemented. Unfortunately, some driver do it completely wrong and return the PHY rate and some don't implement it at all.

batctl tp on the other hand is currently not used for the metric. It uses a minimal stream protocol to transfer data from the current host to the specified host. It doesn't have to be a neighbor and you cannot specify which path it takes. The specified host will acknowledge the received data and the sender can calculate the successfully transmitted bytes using that. In its current form, it is not useful for B.A.T.M.A.N. V and can only be used for minimal performance tests in the mesh.

Does it mean the wireless driver does't support expected_throughput?

Cannot say this for sure. The driver has to be checked. But your output suggest that you are using minstrel_ht - which provides an implementation for expected_throughput. But many kernel versions contain a cfg80211_get_station which isn't correctly initializing the sinfo structure - thus returning uninitialized expected_throughput values in some situations.

How to get the correct expected_throughput from wireless driver？

In which context? From userspace from a shell maybe?

Check the output of `iw dev wlan0 station dump` and search for "expected throughput". If it isn't there than either your driver doesn't support it, your 'iw' doesn't support it or it didn't return a valid value (for unknown reasons).

If you want to get it it via `iw` but instead via nl80211, then please use the NL80211_STA_INFO_EXPECTED_THROUGHPUT attribute which is sometimes returned for a NL80211_CMD_GET_STATION request [1].

So I'm wondering that what's the exact definition of expected_throughput?

I hope Antonio or Felix can provide a better definition. But I would say it is:

The expected throughput is the number of kilobits per second a user will probably transfer (measured on the layers above wifi) when sending data directly to this host. This information is calculated based on the past experience of the driver (actually the rate control algorithm).

And what's the difference from tx/rx bitrate?

TX/RX bitrate is the raw wifi bitrate. It is much higher than the expected throughput in most cases because it doesn't contains correction factors for packet loss, IFS/aggregation and so on. And it is just the info about a single frame which was received/transmitted - not a more complex value calculated based on the statistics gathered from the past transfers.

Kind regards, Sven

[1] https://git.kernel.org/pub/scm/linux/kernel/git/jberg/iw.git/tree/station.c?... [2] https://patchwork.kernel.org/patch/10449857/