From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass smtp.mailfrom=lang.hm; dkim=fail; arc=none (Message is not ARC signed); dmarc=none Received: from mail.lang.hm (wsip-70-167-213-146.ph.ph.cox.net [70.167.213.146]) by mail.toke.dk (Postfix) with ESMTPS id 66A3811CF2F6; Sun, 07 Jun 2026 08:49:34 +0200 (CEST) Received: from [10.2.3.133] (unknown [10.2.3.133]) by mail.lang.hm (Postfix) with ESMTP id A58522277B3; Sat, 6 Jun 2026 23:49:31 -0700 (PDT) Date: Sat, 6 Jun 2026 23:49:26 -0700 (MST) From: David Lang To: Sebastian Moeller cc: Frantisek Borsik , codel@lists.bufferbloat.net, bob.mcmahon@umbernetworks.com, dan , Cake List , Make-Wifi-fast , bloat In-Reply-To: Message-ID: References: <0oq1n88q-36qn-p6s7-699s-p4nr0440p950@ynat.uz> <8e14c6935753c6263351ad00ec59b9cb@umbernetworks.com> <055e42685cddfa4c1a4ff4da089996eb@umbernetworks.com> <7455E3B4-7FB4-4D40-A900-B31151D12F6F@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Message-ID-Hash: 7WIHKW4ZDXVGO6UO54XQWZ4LECWASQMH X-Message-ID-Hash: 7WIHKW4ZDXVGO6UO54XQWZ4LECWASQMH X-MailFrom: david@lang.hm X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list Subject: [Make-wifi-fast] Re: [Bloat] Re: [Codel] [Rpm] Re: Re: [Cake] "Fi-Wi is a new forwarding plane for wireless" - Bob McMahon List-Id: Lets make wifi fast again! Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Sebastian Moeller via Bloat wrote: >> On May 25, 2026, at 14:45, Frantisek Borsik wrote: >> > and still under WiFi-limited scenarios h++ps://test.libreqos.com shows latency > excursions into thte 500-900ms range. For my taste that certainly leaves ample > room for improvements. Sure, when I get closer to the AP so WiFi throughput > exceeds WAN throughput my WAN shaper kicks in and I get decent test results > (with no noticeable increase in latency-under-load), but that is a work-around > only. this tells me that the bandwidth estimates on wifi are fixed, when they need to be dynamic. (or set much lower) When you are too far from the wifi, you aren't getting enough throughput to trigger the shaping, it's sending it all out to the wifi chip thinking that it's operating at the advertised speed. so what we are needing is a feedback loop from the wifi layer to the shaping layer. Fi-Wi attempts to move all of the protocol to the main cpu to give it the visibility, but I'd bet that we can do better with the stats that we have. If we can (for now) ignore the problem of a rapidly moving station, and look at what I will argue is a more typical problem of someone sitting at a desk a good way away from the AP, then later moving to a different desk closer to the AP and wanting to get the best performance in both cases, we could have a script look at the wifi stats/queues/throughput numbers periodically and tweak the cake bandwidth limits to stay within range (say sample every minute, with older info remaining valid when idle, but decaying fairly quickly as new samples arrive so that one bad sample doesn't mess things up too badly, but you adjust to new conditions within a relatively small number of samples it would take a bit of time to get to the right number when conditions change, but it would get there. I recognize that you cannot know the throughput without trying to use it, but you may be able to make a guess as to the amount of idle airtime (subject to hidden transmitters) and make an estimate as to the available headroom based on the throughput in each direction of your recent speeds and airtime used. David Lang