Re: [PATCH RFC] batman-adv: BATMAN V: use/prefer 11s airtime link metric

[Marek Lindner <marek.lindner@mailbox.org>]

On Sunday, 19 January 2025 04:20:46 CET Andrew Strohman wrote:
> In my case, my 2.4ghz radio driver uses minstrel for rate control,
> so throughput estimates are derived using sta_get_expected_throughput().
> For me, this estimation is chronically an over estimate. The 5ghz radio
> does rate control in hardware, so we cannot use the
> sta_get_expected_throughput() method for it.
>
. [..]
> I'm suggesting that we make an effort to make the throughput
> calculation method consistent across radios. 

That's certainly an interesting observation but seems irrelevant to the patch 
proposal you are responding to. Feel free to propose a code change that aims 
to unify the chosen metric source across all radios on the same AP. With the 
current implementation, this is left to the administrator.


> After this patch, it means that the throughput estimation for 5ghz
> stas/neighbors in my network will be derived by examining an exponentially
> weighted average of tx rate with consideration of tx failures. 

After this patch, the 11s throughput estimation is available as a metric 
source. That's all. The patch does not even attempt to address your concern.


> If this new fallback method results in in more similar results to
> sta_get_expected_throughput(), then my problem will be lessened, possibly to
> the point of my network preferring 5ghz (as should be done).

Even if the 11s metric source accidentally provides a similar metric in your 
test setup, there is no guarantee it always will. Again, your are conflating 
your desired outcome with a random patch which isn't trying to do what you 
want it to do.


> OK, thanks. If you're confident that sta_get_expected_throughput()
> returns a result that reflects the recent or likely external contention on
> the operating frequency, that's good to know.

Feel free to read up on how minstrel arrives at the expected throughput. 


> Like I noted in my original message, I was seeing the estimated throughput
> as 150Mb/s for the sta_get_expected_throughput() method, while really
> only able to tx at ~25Mb/s.

Am I right assuming this '~25Mb/s' was measured using iperf or some other 
speed test? The numbers minstrel provides are in a completely different ball 
park and can not be compared to WiFi throughput numbers. You are also not 
taking into account what I have already explained why getting 'accurate' 
throughput numbers is meaningless.


> I'll now be debugging under the assumption that something else causes
> overestimation in my case.

You are still stuck on over / under estimation. In this email alone you are 
mentioning it 6 times. Whether there is over or under estimation is 
irrelevant. Consistency is relevant. 

Cheers,
Marek