Re: [B.A.T.M.A.N.] Fw: What's the exact definition of expected_throughput in BATMAN-ADV V?

Re: [B.A.T.M.A.N.] Fw: What's the exact definition of expected_throughput in BATMAN-ADV V?

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 4825 bytes --]

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?id=6ab936f0458c62b1de3a5af8af8d9a3b092cbfac#n412
[2] https://patchwork.kernel.org/patch/10449857/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]