From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00::f03c:91ff:feae:7028]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 6F7CB3BA8E for ; Sun, 10 Feb 2019 15:40:47 -0500 (EST) Received: from dancer.taht.net (unknown [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 18E7721455; Sun, 10 Feb 2019 20:40:45 +0000 (UTC) From: Dave Taht To: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= Cc: Jon Pike , make-wifi-fast@lists.bufferbloat.net References: <874l9bperv.fsf@toke.dk> Date: Sun, 10 Feb 2019 12:40:33 -0800 In-Reply-To: <874l9bperv.fsf@toke.dk> ("Toke \=\?utf-8\?Q\?H\=C3\=B8iland-J\?\= \=\?utf-8\?Q\?\=C3\=B8rgensen\=22's\?\= message of "Sun, 10 Feb 2019 21:30:44 +0100") Message-ID: <875ztrxtq6.fsf@taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] bloated ath10k, extra latency at lower rates? 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, 10 Feb 2019 20:40:47 -0000 Toke H=C3=B8iland-J=C3=B8rgensen writes: > Jon Pike writes: > >> This might be a good time to mention an observation I've seen that's >> related to this. >> >> I have noticed about the same as reported, 10's down to single digits >> on my ath9k radios, and a similar 20ms-30ms on the ath10k's. Thats at >> high signal strength and the highest data rates. But, I've also >> noticed that it's different if you get farther out in range, and you >> end up on the slower signaling speeds. >> >> Under those conditions, I'm seeing the ath9k latency rise only >> slightly, maybe to 20-30ms, while the ath10k will go up more >> drastically, like a continuous 100-150ms or more. Been meaning to >> mention it to see if it should be considered as an issue. The C7 has an older version of firmware. It would be interesting to benchmark the -ct version of the firmware.=20 > > Well yeah, I guess it should. To answer both you and Adrian: The > debloating of ath10k is only partial currently. It uses the intermediate > queueing system, but it still has quite a bit of buffering in the > firmware, which is not controlled by the driver. The actual latency > induced by this buffering varies by firmware version; but it sounds > quite likely that it would be worse as the rates drop. > > The fix for this is to control the queue length in the firmware, similar > to what BQL does for Ethernet drivers. The ChromeOS people at Google > already has this as a patch for ath10k, which we are planning to port > upstream to live inside mac80211 on top of the airtime fairness > mechanism that is in the process of being merged. > > So there is some hope that this situation will improve in the future :) > > -Toke > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast