[Make-wifi-fast] AQL patch

[Michael Yartys]

On Sunday, January 24th, 2021 at 20:58, Dave Taht <dave.taht at gmail.com> wrote:

> 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

I ran a couple of multistream TCP downloads to test some fixes Felix made to AQL, but I noticed some strange behaviour unrelated to his patches. While running the tests I started an iperf3 download on my smartphone which cut the throughput on my laptop pretty hard and caused high latency. It looks like the rate fell to 1 mbps or lower. Could this be those side-effects you're talking about: https://forum.openwrt.org/t/aql-and-the-ath10k-is-lovely/59002/200?u=huaracheguarache

>
> 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