[Make-wifi-fast] AQL patch

Dave Taht dave.taht at gmail.com
Sun Jan 24 14:58:25 EST 2021


On Sun, Jan 24, 2021 at 11:48 AM Michael Yartys via Make-wifi-fast
<make-wifi-fast at lists.bufferbloat.net> wrote:
>
> Hi, Dave
>
> A couple of days back you talked about wanting to send in a patch to OpenWrt to lower the CoDel target in AQL to 10 ms. I was thinking about taking a shot at doing it myself, and I was looking at the patch you provided in the AQL discussion thread on the OpenWrt forum for some pointers: https://forum.openwrt.org/t/aql-and-the-ath10k-is-lovely/59002/80
>
> I'm having some questions about the following part:
>
> -       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;
> -       }
> +       sta->cparams.target = MS2TIME(5);
> +       sta->cparams.interval = MS2TIME(100);
> +       sta->cparams.ecn = true;
>
> So in this part the code has a different target and interval when the throughput is low than when it's high. In addition ECN is disabled at low rates. You patch simply removes this in favour of keeping ECN on and having a set target and interval regardless of rate. Is this the right way of doing it, or should a patch ideally keep the rate dependent logic but change the targets and intervals? In that case we should probably do some more testing and tuning to figure out the right values.
>
> Michael
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast

I pointed elsewhere in that thread that I felt some of that patch was
wrong, and that there was probably some other problem... and then I
dropped out of development and just made music all year. I am trying
to get back into the 2021 phase of openwrt's release.

Anyway... for 802.11 on 2.4ghz, the lowest rate you can do is fall back
to 1Mbit, which has really lousy side-effects on codel's target, which needs
to get bumped up to 13ms, at minumum at that rate. In the kernel
mainline. Doing something that was 5ghz specific in the mainline
was an idea....

BUT:

In openwrt's case they disable 802.11g rates nowadays so there is less
need to be so gnarly about coping with falling to 1Mbit. 5ghz runs at
a base rate of 6mbits, so a 5ms target was feasible there... but
needed testing.

Secondly the original code was always wrong in two ways: If you have
more than 5 stations it always falls back to really gentle parameters.
ARGUABLY, having something that used active stations rather than total
stations might be a good way to gentle the curve, but it didn't do
that. (our testing was mostly against 4 stations and the real world
is generally larger than that. So while the fq portion of fq-codel and
the airtime fairness bits are hugely useful, in the field the codel-ly bit
was a great deal less effective than it could have been)

given the size of a txop and the structure of things elsewhere, it did
seem that 8-10ms for the target was the right number, and some testing
seemed to show that... certainly that was what I deployed on my testbed
here...

but, it seemed that the biggest thing blowing things up nowadays was
too many darn hw retries against slow stations, which
is elsewhere in the code or buried in the driver or firmware. And there
were other bugs on that thread. My head exploded.... :/

There's a good paper on fixing hw retry out
there... just stopping at two retransmits at the lowest rate would help a lot.

Rate limiting and interleaving multicast bursts would also make a big difference

Since make-wifi-fast has had zero funding for 4 years, doing anything
complicated was pretty difficult, but I hope we get some this year to
help carry openwrt and linux into 2021!

I don't see any reason to arbitrarily disable ecn at this point.

So I'd love to see testing at 10ms target, keeping ecn on, and seeing
what happens. Love even more to tackle the multicast and retransmit
problems also. Thx for looking the code over!

-- 
"For a successful technology, reality must take precedence over public
relations, for Mother Nature cannot be fooled" - Richard Feynman

dave at taht.net <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729


More information about the Make-wifi-fast mailing list