Hi,
Thanks for taking your time to look into this and the detailed explanations!
Generally, the issues both patches try to address make sense to me.
On Thu, Sep 28, 2023 at 02:39:36PM +0200, Remi Pommarel wrote:
Let's consider the below topology
[...]
However the following formula seems to be a more realistic approximation of PT_ac:
PT_ac = PT_ab * LT_bc / (PT_ab * LT_bc)
Typo, I guess, as this would always be 1? What is actually implemented makes more sense to me.
[...]
- return min_t(u32, lth, oth);
- /* OGM throughput was divided by two for retrocompatibility sake */
- oth *= 2;
- return oth * lth / (oth + lth);
Could we end up here with a (forged?) OGM that has both the new half duplex flag set and a throughput value of 0? While also having an lth of 0, therefore dividing by zero here?
In the following scenario:
+-------+ ch.1 +-------+ ch.2 +-------+ ch.2 +-------+ | Orig0 | <----- | Orig1 | <------ | Orig2 | <------ | Orig3 | +-------+ 300 +-------+ 30000 +-------+ 110 +-------+ ^ | | ch.3 | +-----------------------------------+ 100
Would the results on Orig2 to Orig1 be these? - via Orig2: 300*110 / (300+110) = 80.5 - via Orig1: 100 <- selected
While it should have been this? - via Orig2: 30000*110 / (30000+110) = 109.6 <- selected - via Orig1: 100
But we can't calculate the latter on Orig3, because we don't know the two hop neighbor link throughput? Or am I missing something?
Also, this seems to assume that time slices are divided equally. That's probably only be true for WiFi drivers that have airtime fairness changes integrated? So only recent versions of mt76, ath9k and ath10k? Has anyone verified that this works fine not only in AP but also in 11s mode?
And a third concern, but we'd probably have this issue with both our current and your suggestion: Would we be off again 802.11be and its "Multi-Link Operation" in the future?
Regards, Linus