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
