From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 149573B29E for ; Fri, 4 Aug 2023 07:04:17 -0400 (EDT) Received: by mail-pf1-x429.google.com with SMTP id d2e1a72fcca58-686f8614ce5so1843840b3a.3 for ; Fri, 04 Aug 2023 04:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691147050; x=1691751850; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=zIUxYtufbcwUHtDQd0gMASnXyoHtRYUVaoyQboEuXJM=; b=ACEzEbCFV1rXTKzx05LxOkBf70Q7zXIpfCgLN2krNbIV9bgi3VY998D2GiDhqf/Y6V yrX13DsnWUX6jQqsZPUlfQc11z1JKuiabx/zvlyz74FR+HyQMofxs3tvp7UP1RL+4WSv iAVrdR/o88jBZ1JBoolgvw9MBp5LRrjW3fBzENQhJeI4QA+/Jog8d75Fft1sc3TvWHvO I0dEvBjunR1kJ3kZzSi+a2o7TxJ005adZIE3SD7zILWz3fWCh0yW0C31T1X/kqyk7a3k lGMV5IKf7k+y0nHWi45Ct5w1NkUEXhBkk+VAYigqbz/HI+nW2jWc7WOUYzZs7OSMuWUW 6ozg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691147050; x=1691751850; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=zIUxYtufbcwUHtDQd0gMASnXyoHtRYUVaoyQboEuXJM=; b=UyGylT368ua/jlvHKJZKK2jqeU8ESrBr3W30h9ROEw9PUDjkURQ9j/JNkD9LmOz6od u21OwI1+Jo2pnggI87lkN7VWusR0qb5FXwlK8m6beIFkO565y5nkWKKjCYHFcQAx7eRT VAXBMM93eYfBicMN/uVccn3t+PR+M29nknfRIAOyat2ETtagQkNV/BLGEHdfLVXsjaoH c7aGnqhjadz/CkZaGLv5k3FkBaf3CxocVZ7I4LdnQGJXz/SaXaZm9TC2fxUE2XOQmvzg /K9egwEcqeG6qkPUPS9L2lpFpQLzIzIgwYU9E5T6XRoOjHxkB8yP1VoILhDKkOrIpC2H mh0g== X-Gm-Message-State: AOJu0YxZbIN7czbrDPJiGb564VHFxmfOOqDUN15GAa74NHqhH/9Qgk1L tLWkZp2xjEenlHixPGEMTLi2DSfSRqxkpZyXSOQvFpPn X-Google-Smtp-Source: AGHT+IFmkGPoYbXUJJ53W0gyNLUf0CBliGd0ElJU0RLnn8lG6lr3dPkpMf1G3LBYqNJIHJYyHizJcWpI9dbbKxGYYs8= X-Received: by 2002:a17:90b:e0e:b0:269:1e3f:a54d with SMTP id ge14-20020a17090b0e0e00b002691e3fa54dmr1335436pjb.10.1691147050388; Fri, 04 Aug 2023 04:04:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Taht Date: Fri, 4 Aug 2023 04:03:58 -0700 Message-ID: To: Make-Wifi-fast , OpenWrt Development List , linux-wireless Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] a nuking the mac80211 changing codel parameters 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: Fri, 04 Aug 2023 11:04:17 -0000 I cannot help but wonder what the results have been on people applying this patch over the past 6 months? On Tue, Dec 20, 2022 at 12:24=E2=80=AFPM Dave Taht wr= ote: > > This is the single, most buggy, piece of code in "my" portion of wifi > today. It is so wrong, yet thus far I cannot get it out of linux or > find an acceptable substitute. It makes it hard to sleep at night > knowing this code has been so wrong... and now in millions , maybe > even 10s of millions, of devices by now.... Since I've been ranting > about the wrongness of this for years, I keep hoping that we can > excise it, especially for wifi6 devices and even more especially on > 6ghz spectrum... but just about everything, somehow, would benefit > hugely if we could somehow do more of the right thing here. > > I'd tried, last time I got this bee in my bonnet, tried to nuke this call= here: > > https://forum.openwrt.org/t/reducing-multiplexing-latencies-still-further= -in-wifi/133605/ > > As it is, I really encourage folk, especially with mt79 and to some > extent mt76 ac or ath10k, to try out the attached patch, measure tcp > rtts, and throughput, etc. A slightly less aggressive patch might suit > wifi-n.... > > Maybe there's a reason for keeping this code in linux wifi that I do > not understand. But here are my pithy comments as to why this part of > mac80211 is so wrong... > > static void sta_update_codel_params(struct sta_info *sta, u32 thr) > { > - if (thr && thr < STA_SLOW_THRESHOLD * sta->local->num_sta) { > > 1) sta->local->num_sta is the number of associated, rather than > active, stations. "Active" stations in the last 50ms or so, might have > been a better thing to use, but as most people have far more than that > associated, we end up with really lousy codel parameters, all the > time. Mistake numero uno! > > 2) The STA_SLOW_THRESHOLD was completely arbitrary in 2016. > > - sta->cparams.target =3D MS2TIME(50); > > This, by itself, was probably not too bad. 30ms might have been > better, at the time, when we were battling powersave etc, but 20ms was > enough, > really, to cover most scenarios, even where we had low rate 2Ghz > multicast to cope with. Even then, codel has a hard time finding any > sane drop > rate at all, with a target this high. > > - sta->cparams.interval =3D MS2TIME(300); > > But this was horrible, a total mistake, that is leading to codel being > completely ineffective in almost any scenario on clients or APS. > 100ms, even 80ms, here, would be vastly better than this insanity. I'm > seeing 5+seconds of delay accumulated in a bunch of otherwise happily > fq-ing APs.... > > 100ms of observed jitter during a flow is enough. Certainly (in 2016) > there were interactions with powersave that I did not understand, and > still don't, but > if you are transmitting in the first place, powersave shouldn't be a > problemmmm..... > > - sta->cparams.ecn =3D false; > > At the time we were pretty nervous about ecn, I'm kind of sanguine > about it now, and reliably indicating ecn seems better than turning it > off for > any reason. > > - } else { > - sta->cparams.target =3D MS2TIME(20); > - sta->cparams.interval =3D MS2TIME(100); > - sta->cparams.ecn =3D true; > - } > > And if we aint gonna fiddle with these, we don't need these either. > > In production, on p2p wireless, I've had 8ms and 80ms for target and > interval for years now, and it works great. It is obviously too low, > for those that > prize bandwidth over latency (I personally would prefer TXOPs shrink > intelligently as well as bandwidth, as you add stations, some of which > happens naturally by fq-codels scheduling mechanisms, others don't, I > even run with 2ms txops by default on everything myself) > > + return; > > Ideally we could kill this entire call off entirely. > > } > > A pre-thx for anyone actually trying the attached patch and reporting > back on any results. > > https://forum.openwrt.org/t/reducing-multiplexing-latencies-still-further= -in-wifi/133605/ > > > -- > This song goes out to all the folk that thought Stadia would work: > https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698136666= 5607352320-FXtz > Dave T=C3=A4ht CEO, TekLibre, LLC --=20 Podcast: https://www.youtube.com/watch?v=3DbxmoBr4cBKg Dave T=C3=A4ht CSO, LibreQos