Rate-ctrl experience gained with ath10k

[Ben Greear <greearb@candelatech.com>]

So, I've been trying to understand why the ath10k-rate ctrl was acting
so poorly in my 20-station UDP tx case.  I wrote that wifi-diag tool,
and it gave some clues, but only in retrospect were they obvious :)

The problem in general was that a single station could upload, at say 500Mbps,
but 20 stations could only do about 325Mbps.  If we fixed the MCS at 3x3 MCS7,
then the 20 station upload test ran about 490Mbps.

There were several optimizations I made in the ath10k firmware rate-ctrl.  One
was to penalize rates with higher PER (packet error rate) more than the old algorithm did.  This helped
a small bit, but not enough (around 350-370Mbps total throughput).

Then, after adding logs I noticed that each station was probing once about every 5 ampdu
chains, or almost 20% of the time!  These probe AMPDUs are limited to a max of 4 AMSDUs,
and that explains why my 'bad' case showed 17% of the AMPDU chains were 4 in length in
my wifi-diag output.

I changed the firmware to take number of active stations into account, and increase the
75ms probe interval by up to a factor of 5.  I also probe less often when the probed
rate has PER > 5 or the last probe had a dropped frame.

And, I allow probing with AMPDU chains of up to 16 AMSDU instead of just 4.

Together this gets me up to about 460Mbps in this test case.   Still not quite as good
as fixing the MCS at 7, but good enough I think.

Here's hoping this email will let other folks poking at rate-ctrl have a faster
time at fixing things than I did.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com