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
