[Make-wifi-fast] fixing 6 things with AQL and the current implementation of codel for wifi

[Dave Taht]

This snippet of code needs work, and it would be good to expose a few
parameters to userspace.

static void sta_update_codel_params(struct sta_info *sta, u32 thr)
{
        if (!sta->sdata->local->ops->wake_tx_queue)
                return;

        if (thr && thr < STA_SLOW_THRESHOLD * sta->local->num_sta) {
                sta->cparams.target = MS2TIME(50);
                sta->cparams.interval = MS2TIME(300);
                sta->cparams.ecn = false;
        } else {
                sta->cparams.target = MS2TIME(20);
                sta->cparams.interval = MS2TIME(100);
                sta->cparams.ecn = true;
        }
}
1) The ath10k codepath does its own rate control and never hits this,
thus the target and ecn parameters stay at the current 20ms. At one
level I'm comforted because it shows up in the data as working
correctly, if not optimally.

2) sta->local->num_sta should be something like an ewma of most
recently seen stations

and

3) bloating the target and interval arbitrarily

4) Flipping ecn behavior on and off arbitrarily

5) It's not configurable from userspace

6) the behaviors of n, ac and ax are different. In theory, at least,
ax can schedule to many stations at the same time on their own
dedicated channels, ac, can do mu-mimo (helps to have short txops and
a gang scheduler), n has both 2.4ghz and 5ghzsupport.

There are several major scenarios to think about. It's kind of
optimized for the "4 people in a home" strategy, which is what we were
optimizing for - and we were working primarily with 2.4ghz wifi, with
a base rate of 1mbit. A lot of 2.4ghz stuff disallows b and g rates
nowadays, and if that's happening, we don't have to worry about the
1mbit rate so much.

I've pointed out that hardware retries are pretty darn high (I've seen
over a second of retries) and affect the codel performance, I'd really
like to reduce those also, sanely. In fact, that's probably more
important than twiddling with codel....

p2p links: In this case I've long found a 6ms target to be more than
adaquate. I'd like to experiment with even less

small wifi APs - here, optimizing for 4 stations at full bandwidth
seems like a decent default, but still, 20ms target seems like a lot.

big wifi APs - say, 100 clients - no matter what we do, the link will
bloat, and the size of txop ultimately shrink to a very small value.
Some service time per station is better that starving some entirely,
IMHO, but perhaps being able to configurably clamp the min txop size
to something greater than the min would help.

clients: Here, we finally have TSQ working "right", but it's kind of
unknown what the right target might be. OSX used 10ms.

And there are so many other things I've longed for from some firmware
somewhere, like "A TX or RX is almost done" interrupt - so we didn't
have to commit data to the chip until it had a greater chance of being
ready.



-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729