From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch [185.70.40.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id F24553B2A4 for ; Sun, 24 Jan 2021 15:43:36 -0500 (EST) Date: Sun, 24 Jan 2021 20:43:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1611521015; bh=BH3Dmajvx9TWHV5ex4s00oEQWdfJ58BR01SlAlyPe/I=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=GBUPW2MLuqMlLSVJZSWKdHx7FAQZ0at0oS+Lo7lZbzeGBvopHhj1qN0SrJdJIRhI2 Cim+F/gSMpc3IV7sbSiAgpQnVM6oTMdPkHQSvI7lshG1VwYHaytwS9bcbflNNbWJMx 2n5Y7VNVgphuC7uvJv57Qz1st+gluADo0cj38uvc= To: Dave Taht From: Michael Yartys Cc: Michael Yartys via Make-wifi-fast Reply-To: Michael Yartys Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch Subject: Re: [Make-wifi-fast] AQL patch X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2021 20:43:37 -0000 On Sunday, January 24th, 2021 at 20:58, Dave Taht wro= te: > On Sun, Jan 24, 2021 at 11:48 AM Michael Yartys via Make-wifi-fast > > make-wifi-fast@lists.bufferbloat.net wrote: > > > Hi, Dave > > > > A couple of days back you talked about wanting to send in a patch to Op= enWrt to lower the CoDel target in AQL to 10 ms. I was thinking about takin= g 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 =3D MS2TIME(50); > > > > > > - sta->cparams.interval =3D MS2TIME(300); > > > > > > - sta->cparams.ecn =3D false; > > > > > > - } else { > > > > > > - sta->cparams.target =3D MS2TIME(20); > > > > > > - sta->cparams.interval =3D MS2TIME(100); > > > > > > - sta->cparams.ecn =3D true; > > > > > > - } > > > > > > > > - sta->cparams.target =3D MS2TIME(5); > > > > > > - sta->cparams.interval =3D MS2TIME(100); > > > > > > - sta->cparams.ecn =3D true; > > > > > > > > So in this part the code has a different target and interval when the t= hroughput is low than when it's high. In addition ECN is disabled at low ra= tes. 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 testin= g and tuning to figure out the right values. > > > > Michael > > > > Make-wifi-fast mailing list > > > > Make-wifi-fast@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 ne= eds > > 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 t= o 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 l= ike 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=3Dhuaracheguarache > > 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 bi= t > > 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 dif= ference > > 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@taht.net CTO, TekLibre, LLC Tel: 1-831-435-0729