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

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

Hi Andrew,

Thanks for your feedback!

> Currently, that means tx rate / 3 (which is an under-estimate).

I think if I recall correctly this was intentional that the
fallback typically under-estimates. Generally speaking better to
under-estimate than over-estimate for a fallback mechanism which
uses a worse approach. The tx rate / 3 fallback is more pessimistic
by design.

> 
> This results in my network perferring 2.4ghz paths when it should be preferring
> 5ghz paths.

Makes sense from the original design idea. The 5ghz radio does not
provide us with an accurate expected throughput from its
locked-up, hidden rate control, so we are better safe than sorry
here and under-estimate it.

But shouldn't this also mean that this patch has a high chance of
fixing the issue in your setup? With this patch you should get a
higher, more "realistic"/comparable estimate for your 5ghz radio?

> The problem is that throughput calculation method is not consistent
> across radios.

Full ACK.

> 
> I know that both these methods of throughput estimation are trying to estimate
> the same thing, but they are implemented differently.

ACK.

> There implementation details
> can result in a bias to over or under estimation.
> 
> I'm suggesting that we make an effort to make the throughput
> calculation method consistent across radios. More specifically,
> if one radio doesn't support sta_get_expected_throughput(),
> then we shouldn't use that method for any radio -- all radios
> should use the same fallback mechanism.

This one I'm not sure of... different radios can still use
different rate control algorithms. One radio might prefer to use
higher WLAN bitrates and tolarate more loss. While another radio
might be more cautious and might generally use lower WLAN bitrates,
to maybe achieve less loss.

And I'm also wondering if that would result in the wrong overall
incentives. Should vendors who give us more useful information
really be punished for that, by us falling back to the method used
with the worst, most locked-up vendor?

> [...]
> In my case, I also found that sta_get_expected_throughput() delivers
> over-estimates.

Or the other one under-estimates ;-). Another thing to keep in
mind I think an expected throughput measurment would be closer
to a UDP than a TCP test. I guess your measurements were with TCP?
On WiFi UDP and TCP throughput can differ quite a bit, at least
from my experience.

Regards, Linus