From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 5FE713CB47 for ; Fri, 13 Dec 2019 13:13:22 -0500 (EST) Received: by mail-il1-x135.google.com with SMTP id p8so141305iln.12 for ; Fri, 13 Dec 2019 10:13:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=iQAsFC9iNC9wyup/FKQxIc+F4FPmXh4H6SPOclINUCU=; b=d7vzEr7OHQuYcgIQka3LLjkoHWch4niEI1s+Bky/e9r91ngZB7qZ6DG0LIhkLH/PwP aX0EEfUBgsmfqKTh5G4o34hG8YTf7Uz8BUwpctlT5ICf59pDFHvX7L3rU3/WBG9/Wo4D DajSaqd6WtxtvzGtWxd5uHUjtzC/Ady09hYniize4QkY1kFpUMB3Uag30mx3ldxm4n78 lkPDkb7Z+jvDAYywBwD62j+xRQ0JJG2929s99NOoyfCE5qGEMeeOexicBDOQeCG8bZjZ NGnuF4y9OHLEoMLAce5iKpTU+RkB15kvHrw/auSTQNALwU2iryYi1i9mm0q4avCa3/f6 DvqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=iQAsFC9iNC9wyup/FKQxIc+F4FPmXh4H6SPOclINUCU=; b=Gp2Va6lFZFKftyVCqk26RSz3hEhp2MGp0wS32/ARfm4+xHNfpcZyYKl+wpaKIPSJX9 jMTCDKQrDOJp73m6qWOpZlhONRjc/0atwiex/GtWhYYAXp9vLnxSOD3kslWohc/KTLE5 oNMDRg6ESw776xzjoVO05pgqdrO7reEkXciaV3vNVCzAz3oSqOYawN1PvIRelGn3Fmyr 9HwIj7Q2juOrhRurY70rJ9Q9h07qradlDV8YY1a+KcfRMulvcFyNKhyZSqaWKyHpm1sK Nfid8nT52Lx4iZeN907H1VZHPkrWTL5JVMU9+DI0ktraMo9NUwL60GYeQdBgEQkEqLYZ gn9A== X-Gm-Message-State: APjAAAVj4nvsl5PnzOzBuy92XInsyO8ooMP6PzDwEKJYgj7PBdTY3G+1 aBb5MlGqLKeggmAhe6s9VMf08iYL3a+ab2lj3fLtb7DF X-Google-Smtp-Source: APXvYqxwmK7GZ60Jcd5QkUQ0VV96LZkEfc5yaAZbdQ7lYVjn6PKYRlqSTjq5cT6fONKZyXvHqIuXD5bb8A9abZ+JE4Q= X-Received: by 2002:a92:ba93:: with SMTP id t19mr662024ill.0.1576260801513; Fri, 13 Dec 2019 10:13:21 -0800 (PST) MIME-Version: 1.0 From: Dave Taht Date: Fri, 13 Dec 2019 10:13:08 -0800 Message-ID: To: Make-Wifi-fast Cc: Kan Yan , Ben Greear Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: [Make-wifi-fast] fixing 6 things with AQL and the current implementation of codel for wifi 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, 13 Dec 2019 18:13:22 -0000 This snippet of code needs work, and it would be good to expose a few parameters to userspace. static void sta_update_codel_params(struct sta_info *sta, u32 thr) { if (!sta->sdata->local->ops->wake_tx_queue) return; 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; } } 1) The ath10k codepath does its own rate control and never hits this, thus the target and ecn parameters stay at the current 20ms. At one level I'm comforted because it shows up in the data as working correctly, if not optimally. 2) sta->local->num_sta should be something like an ewma of most recently seen stations and 3) bloating the target and interval arbitrarily 4) Flipping ecn behavior on and off arbitrarily 5) It's not configurable from userspace 6) the behaviors of n, ac and ax are different. In theory, at least, ax can schedule to many stations at the same time on their own dedicated channels, ac, can do mu-mimo (helps to have short txops and a gang scheduler), n has both 2.4ghz and 5ghzsupport. There are several major scenarios to think about. It's kind of optimized for the "4 people in a home" strategy, which is what we were optimizing for - and we were working primarily with 2.4ghz wifi, with a base rate of 1mbit. A lot of 2.4ghz stuff disallows b and g rates nowadays, and if that's happening, we don't have to worry about the 1mbit rate so much. I've pointed out that hardware retries are pretty darn high (I've seen over a second of retries) and affect the codel performance, I'd really like to reduce those also, sanely. In fact, that's probably more important than twiddling with codel.... p2p links: In this case I've long found a 6ms target to be more than adaquate. I'd like to experiment with even less small wifi APs - here, optimizing for 4 stations at full bandwidth seems like a decent default, but still, 20ms target seems like a lot. big wifi APs - say, 100 clients - no matter what we do, the link will bloat, and the size of txop ultimately shrink to a very small value. Some service time per station is better that starving some entirely, IMHO, but perhaps being able to configurably clamp the min txop size to something greater than the min would help. clients: Here, we finally have TSQ working "right", but it's kind of unknown what the right target might be. OSX used 10ms. And there are so many other things I've longed for from some firmware somewhere, like "A TX or RX is almost done" interrupt - so we didn't have to commit data to the chip until it had a greater chance of being ready. --=20 Make Music, Not War Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-435-0729