From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id AFC0E3B2A4 for ; Sun, 24 Jan 2021 14:58:37 -0500 (EST) Received: by mail-io1-xd2c.google.com with SMTP id z22so22365628ioh.9 for ; Sun, 24 Jan 2021 11:58:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2mAPVVF4LbIbigalRSt/i2fEzBzVMCnGeyBn2rt7N5Q=; b=pY3r8IHLEOk5md+xkMya7cdQUbc/Js3PoWBJi7pM47VvER+hvL6gRJp+2fBLCHlemp xhlUAqiLfkcSWeKPhlbEQlPvrjEIY1VECwEUHCcLwm6E96efvfIs/c7t10omBsdYPYts FLhImpgX5sJKIYGmerPSEPb0TpXVL6TxFqSG4HHIAEIZ8KuVAdo5lCurV7eVBhKqqX6b ca4FbWxKYGr+oxRVD7Mki1F9hfHN09Jsfk4eJc4IR04EoUvTaS2/MFv83Cpik5i+oCQN p8yTKQHVVopRE/2CGjZEmstvfzHI1JW4ZopfoRZoKpwI0lMWLJBYfihDNWDZbzdf3RJz VJHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2mAPVVF4LbIbigalRSt/i2fEzBzVMCnGeyBn2rt7N5Q=; b=rU5FaEslUfR/eJvp4XPMUz0BsfQ68V59CALToWvYUksRtf1henZZsGtHiRCzz82/IH ZwH7aKODvuxHsiHXy4dZ6QpnzorpnbNujRW4toCWJRYgPet8aMmB68b68N5sxnPIL893 fFVLhBuX9osHGr8mytobEIHapn3ydJQH/CRXugsoGPXGNa0lEz9xWYFCEeOSGKZhy+en awHrzeerMi5lv53GfgaAwoJ8rL8odZppySVQYHgBAfDqlu3dE7ryt+6ycrKNHiVsVcHZ QTR4iV2EKjPNfDRzbA7Zgk+KqXHGmlXtlRNqdCZ2qgkRLl6sfr3sQTOgybWTgDfsVhyk UPNQ== X-Gm-Message-State: AOAM531U9AS5skJ9AOUFzN+okpbc3oJCxxwVMINzEUuAka8AspIIuVDs OUDF0nL/WqWAEoKemOJ/UdEOwryMhJ2DwYenWMM= X-Google-Smtp-Source: ABdhPJyZMOEEL8xKxafpxKT2wiju+GP5I59ajY5xBbANBctadIZfzvkrgEFXX9yez7TjqYuaEtFxeIWH6ReBc3rJOkk= X-Received: by 2002:a92:d107:: with SMTP id a7mr1747130ilb.45.1611518317101; Sun, 24 Jan 2021 11:58:37 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dave Taht Date: Sun, 24 Jan 2021 11:58:25 -0800 Message-ID: To: Michael Yartys Cc: Michael Yartys via Make-wifi-fast Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 19:58:37 -0000 On Sun, Jan 24, 2021 at 11:48 AM Michael Yartys via Make-wifi-fast wrote: > > Hi, Dave > > A couple of days back you talked about wanting to send in a patch to Open= Wrt 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 t= he AQL discussion thread on the OpenWrt forum for some pointers: https://fo= rum.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 thr= oughput is low than when it's high. In addition ECN is disabled at low rate= s. You patch simply removes this in favour of keeping ECN on and having a s= et target and interval regardless of rate. Is this the right way of doing i= t, or should a patch ideally keep the rate dependent logic but change the t= argets 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@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 need= s 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 l= ot. Rate limiting and interleaving multicast bursts would also make a big diffe= rence 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! --=20 "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