From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x142.google.com (mail-il1-x142.google.com [IPv6:2607:f8b0:4864:20::142]) (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 02BD43B29E; Tue, 4 Feb 2020 12:07:37 -0500 (EST) Received: by mail-il1-x142.google.com with SMTP id f70so16524217ill.6; Tue, 04 Feb 2020 09:07: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=bUaXY3ZhJ0J1M0QceVOiGTCm/V6clF3ndPp9SgV5cbs=; b=KaniTr9PIiVE6Dom/UoIB/K9gYtRelAvJJwjuA6V58g0yAaqPJ8K9R/x2GtQZRw6th qHbWvky9pklPw2DdJwWXqLItQ9OwbUkvgr1nVg4YtyaPfjcCcPcCDehlTC7vlFxANIUi KqgzGW8oGEjbRvGtj00Snse5P2zPpsW2sv+i23w8hYNNJiLFirLcuU1T8ombAkjfeQW1 /OCCyRvbxkC4Axm74VQHd1KNAV0+w/59BFlqwYL9hvq3ePifM9vSjJjqR4Ez35Xdu4Dn xf/4m3Ei0js5/XjqlsvYqEhN0jyT+xflUw4ibAPnT5kjPWUbutDsci4V6hNCQWfDoYOT fbGQ== 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=bUaXY3ZhJ0J1M0QceVOiGTCm/V6clF3ndPp9SgV5cbs=; b=KnAZ/9fA6/GLY8/iBF17d4FhtkTZzk7TdlFRkMALRX1umnCaoGH02mWarVH/KUsjhA Hgxnr4P5F8uFV+hegxQn2+DtXLI+ROzbGhu60lzKW6fSkE+by/hBXb/mH2HDfCamK94j 2CdoUGoHAXTjw3XQEjJf08M88A+D0l9nrI1Id4pTu/Ud6lUNvSrPxaaFDnWQkrVrs/hb sAmBzbxKf4Bw1yWtP05E0uQtzHmyZJYc5oTfAS/tg3Myl4JRJ6vS4EUBb67bcS7mBQn/ yT1Td/Vedjrw/BWxOaMFun98BLrGosu7f0Hc7WKhtiySdjtTW01KEs07hKIEf5agTi0F 2cRQ== X-Gm-Message-State: APjAAAUJSULpiVUKPH9ZDMRrOt5Js3w/flWX/DQ30QuvFY5TfigggF7/ 1DJUl92PNEeQGNOpCpPtcfMAZ1zrjsIjm3Gk4hg= X-Google-Smtp-Source: APXvYqxI1ithOn//Vby3lVczpjGnPtyORex965qCZ4jNgAddop+jYQqW38XZ77PLhNrV+Lkdeqpwm7b3sVlPbowDQqQ= X-Received: by 2002:a92:ba93:: with SMTP id t19mr29625155ill.0.1580836057254; Tue, 04 Feb 2020 09:07:37 -0800 (PST) MIME-Version: 1.0 References: <07250850-5FAF-4AB7-9551-0B26D648AF3D@gmail.com> In-Reply-To: <07250850-5FAF-4AB7-9551-0B26D648AF3D@gmail.com> From: Dave Taht Date: Tue, 4 Feb 2020 09:07:25 -0800 Message-ID: To: Jonathan Morton Cc: =?UTF-8?Q?Bj=C3=B8rn_Ivar_Teigen?= , Cake List , Make-Wifi-fast Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] [Cake] Cake in mac80211 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: Tue, 04 Feb 2020 17:07:38 -0000 On Tue, Feb 4, 2020 at 7:25 AM Jonathan Morton wrot= e: > > > On 4 Feb, 2020, at 5:20 pm, Bj=C3=B8rn Ivar Teigen wro= te: > > > > Are there any plans, work or just comments on the idea of implementing = cake in mac80211 as was done with fq_codel? > > To consider doing that, there'd have to be a concrete benefit to doing so= . Research is research! :) Everything is worth trying! There's got to be some better ideas out there, and we have a long list of things we could have done to keep improving wifi had funding not run out. We barely scratched the surface of this list. https://docs.google.com/document/d/1Se36svYE1Uzpppe1HWnEyat_sAGghB3kE285LEl= JBW4/edit > Most of Cake's most useful features, beyond what fq_codel already support= s, are actually implied or even done better by the WiFi environment and the= mac80211 layer adaptation (particularly airtime fairness). In my opinion(s) A) I think ack-filtering will help somewhat on 802.11n, but it's not worth the added cpu cost on an AP and I'd prefer hosts reduce their ack load in the tcp stack (IMHO, others may differ, it's worth trying) B) The underlying wifi scheduler essentially does per host fq better than cake can (because it's layer 2 vs layer 3), as per jonathan's comment above C) Instead of using a 8 way set associative hash and 1024 queues, fq_codel for wifi uses 4096 with a disambiguation pointer for collisions. Seems good enough. D) "cobalt" is proving out better in several respects than pure codel, and folding in some of that makes sense, except I don't know which things are the most valuable considering wifi's other problems E) I'd like to dynamically increase the quantum size as a function of load or number of flows. I'd really like benchmarks of the proprietary versions coming out. Qualcomm has their own fq_codelish thing baked into their firmware now... I have no idea what broadcom is doing... fq-pie? The librerouter is now available. I'd like to try that. Recently I benchmarked red rock cafe in mountain view, which had the best bufferbloat and rrul score of any cybercafe I'd ever tried - they have a mojo networks AP, which arista bought a while back. It was lovely.... I have no idea what they do, but whatever it was it was *good*. I'm really happy see bufferbloat getting fixes everywhere, but really need to add quic to the benchmark suite somehow in order to feel better about people not rewriring tcp headers to do what they want. more importantly: Would really like to get cracking on a wifi 6 version. So far, all the vendors are lying, there is no OFDMA support in anything we've played with. There are some new outer limits there (1000+ devices), a need to do gang scheduling, and per-station firmware, and I'm profoundly unimpressed with proprietary vendor's efforts so far and wish they'd open up their firmware more so more of us could take a crack at it.... I'd really like to get the intel (iwl) version, especially the ax200 chips, ported over to the AQL + fq_codel interfaces, at least. The first attempt went badly, last quarter. Needs eyeballs and time... Would like to find some other wifi chip worth fixing - raspi 4? Some android wifi chip? what? Don't know how the ath11k effort is going... In mainline... I'd like to get the wifi codel target on 5ghz down from 20ms (too much) to 10ms, (or as I run it here to 8ms) in mainline, or at least openwrt, but that would require some benchmarking by multiple folk, and I was waiting for the ath10k ATF code to go upstream first. At least make it tunable. Overall, reducing hw retries to sanity would be a nice thing to attempt in the ath9k, at least. Although the ongoing SCE work (gradual rate reduction) is interesting, I tend to think reducing hardware retries (with increased loss) would have a more dramatic effect on reducing wifi latencies. Presently with the codel target of 20ms in both directions, I get 60-80ms tcp latencies (still better than most fiber!) over wifi with a 20ms target at 70mbits. What happens at 300+, no idea. cynically I think much of the internet is essentially running at a max rwind or swind rather than within athe sawtooth. doing something more sane to rate limit multicast would be good also. It was quite the long list in that google document, back in the day we thought the wifi industry might decide to collaborate in order to meet the 5G threat. > a Cake instance to the wifi interface as well, if you have a need to do s= o. It certainly is feasible to do that. I do that now on several 802.11ac devices that don't have the fq_codel for wifi hooks, preferring to rate limit them well below capacity so as to ensure consistent low latency. It's really neat to see people able to play world of warcraft and other games over the wifi here. ( started deploying ubnt's uap mesh products, reflashed with openwrt, along portions of my wifi backbone . Looking forward to the AQL backport for those, but I hope someone else does it) > > - Jonathan Morton > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake --=20 Make Music, Not War Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-435-0729