Re: [PATCH RFC 2/2] batman-adv: Better half duplex penalty estimation

["Linus Lüssing" <linus.luessing@c0d3.blue>]

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