From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) (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 E67893BA8E for ; Sun, 10 Feb 2019 15:30:46 -0500 (EST) Received: by mail-ed1-f48.google.com with SMTP id h50so7135476ede.5 for ; Sun, 10 Feb 2019 12:30:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=ukzGFmY2631g3Ntrdufa1W7CyStrCTkw9qR2EdIjWno=; b=olqQ7KSobltl19gru/YfwfNjtYLKaqNCSfbCTHAYeK6xNAK43uF2Qz6vJNVyMW1iFN MrZeH3CBTHCbJ8gKLRtg43uHAiNOewCxlooSQrkN7P0LcRlzB+LnmuFAzaa2dXSAvc8C m3izPQKgBxLl6d+UYhlsgK1Q1e+v10tls53bwC4hEtyleIOVVIPWu4mDlhnBSdeY6PY3 sIUfwyJsDDVRuOpyaSiLfoBIbJkdPnwL0m5HrruZZoJr/jQCroYNiLCQcct+LTiEBJqA OCuwSN4k2xxNDMMXNMBTzMcrFPMZGObiJXpIrCySDyYM+kJTn7WSp1+nkXy/GTkszi0o ThuA== X-Gm-Message-State: AHQUAua61mRqKlmPyoXCp70KfdlkKQ3gwSFDWZuMuLJZrnMB6mUxjV6B kx7jgN8Dk9jHXrYIBm2sgvyFxLAFE794wQ== X-Google-Smtp-Source: AHgI3IaYKpeVNXisaxooMPhrUu8FaqU5h1eNgMIsqLV9vCOjqh27TkTF7F/bMU3q+5/JZLFx/yLb6Q== X-Received: by 2002:a50:8f04:: with SMTP id 4mr26044399edy.95.1549830646000; Sun, 10 Feb 2019 12:30:46 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk (alrua-x1.vpn.toke.dk. [2a00:7660:6da:10::2]) by smtp.gmail.com with ESMTPSA id a4sm1869542eje.66.2019.02.10.12.30.45 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 10 Feb 2019 12:30:45 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 7068E1825D3; Sun, 10 Feb 2019 21:30:44 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Jon Pike , make-wifi-fast@lists.bufferbloat.net In-Reply-To: References: X-Clacks-Overhead: GNU Terry Pratchett Date: Sun, 10 Feb 2019 21:30:44 +0100 Message-ID: <874l9bperv.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain 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:30:47 -0000 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. 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