From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail.toke.dk ([52.28.52.200]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gwqX2-0002ku-5v for ath10k@lists.infradead.org; Thu, 21 Feb 2019 15:45:10 +0000 From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= Subject: Re: [PATCH v2 2/2] ath10k: Set sk_pacing_shift to 6 for 11AC WiFi chips In-Reply-To: References: <1533724802-30944-1-git-send-email-wgong@codeaurora.org> <1533724802-30944-3-git-send-email-wgong@codeaurora.org> <87sh3pdtpg.fsf@toke.dk> <87mutue4y8.fsf@toke.dk> <1535967508.3437.31.camel@sipsolutions.net> <87in3m25uu.fsf@toke.dk> <1535975240.3437.61.camel@sipsolutions.net> <878t4i1z74.fsf@toke.dk> <871sa7ylmi.fsf@toke.dk> Date: Thu, 21 Feb 2019 16:42:56 +0100 Message-ID: <87r2c1i1vj.fsf@toke.dk> MIME-Version: 1.0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "ath10k" Errors-To: ath10k-bounces+kvalo=adurom.com@lists.infradead.org To: Grant Grundler , Kan Yan Cc: linux-wireless@vger.kernel.org, Johannes Berg , wgong@qti.qualcomm.com, ath10k@lists.infradead.org, wgong@codeaurora.org R3JhbnQgR3J1bmRsZXIgPGdydW5kbGVyQGdvb2dsZS5jb20+IHdyaXRlczoKCj4gT24gVGh1LCBT ZXAgNiwgMjAxOCBhdCAzOjE4IEFNIFRva2UgSMO4aWxhbmQtSsO4cmdlbnNlbiA8dG9rZUB0b2tl LmRrPiB3cm90ZToKPj4KPj4gR3JhbnQgR3J1bmRsZXIgPGdydW5kbGVyQGdvb2dsZS5jb20+IHdy aXRlczoKPj4KPj4gPj4gQW5kLCB3ZWxsLCBHcmFudCdzIGRhdGEgaXMgZnJvbSBhIHNpbmdsZSB0 ZXN0IGluIGEgbm9pc3kKPj4gPj4gZW52aXJvbm1lbnQgd2hlcmUgdGhlIHRpbWUgc2VyaWVzIGdy YXBoIHNob3dzIHRoYXQgdGhyb3VnaHB1dCBpcyBhbGwgb3Zlcgo+PiA+PiB0aGUgcGxhY2UgZm9y IHRoZSBkdXJhdGlvbiBvZiB0aGUgdGVzdDsgc28gaXQncyBoYXJkIHRvIGRyYXcgc29saWQKPj4g Pj4gY29uY2x1c2lvbnMgZnJvbSAoZm9yIGluc3RhbmNlLCBmb3IgdGhlIDUtc3RyZWFtIHRlc3Qs IHRoZSBhdmVyYWdlCj4+ID4+IHRocm91Z2hwdXQgZm9yIDYgaXMgMzMxIGFuZCAzNzkgTWJwcyBm b3IgdGhlIHR3byByZXBldGl0aW9ucywgYW5kIGZvciA3Cj4+ID4+IGl0J3MgMzI2IGFuZCAzNzEg TWJwcykgLiBVbmZvcnR1bmF0ZWx5IEkgZG9uJ3QgaGF2ZSB0aGUgc2FtZSBoYXJkd2FyZQo+PiA+ PiB1c2VkIGluIHRoaXMgdGVzdCwgc28gSSBjYW4ndCBnbyB2ZXJpZnkgaXQgbXlzZWxmOyBzbyB0 aGUgb25seSB0aGluZyBJCj4+ID4+IGNhbiBkbyBpcyBncnVtYmxlIGFib3V0IGl0IGhlcmUuLi4g OikKPj4gPgo+PiA+IEl0J3MgYSBmYWlyIGNvbXBsYWludCBhbmQgSSBhZ3JlZSB3aXRoIGl0LiBN eSBjb3VudGVyIGFyZ3VtZW50IGlzIHRoZQo+PiA+IG9wcG9zaXRlIGlzIHRydWUgdG9vOiBtb3N0 IGlkZWFsIGJlbmNobWFya3MgZG9uJ3QgbWVhc3VyZSB3aGF0IG1vc3QKPj4gPiB1c2VycyBzZWUu IFdoaWxlIHRoZSBkYXRhIHdnb25nIHByb3ZpZGVkIGFyZSB3YXkgbW9yZSBub2lzeSB0aGFuIEkK Pj4gPiBsaWtlLCBteSBvdmVyYWxsICJjb25maWRlbmNlIiBpbiB0aGUgImNvbmNsdXNpb24iIEkg b2ZmZXJlZCBpcyBzdGlsbAo+PiA+IHBvc2l0aXZlLgo+Pgo+PiBSaWdodC4gSSBndWVzcyBJIHdv dWxkIGp1c3QgcHJlZmVyIGEgc2xpZ2h0bHkgbW9yZSBjb21wcmVoZW5zaXZlCj4+IGV2YWx1YXRp b24gdG8gYmFzZSBhIDR4IGluY3JlYXNlIGluIGJ1ZmZlciBzaXplIG9uLi4uCj4KPiBLYWxsZSwg aXMgdGhpcyB3aHkgeW91IGRpZG4ndCBhY2NlcHQgdGhpcyBwYXRjaD8gT3RoZXIgcmVhc29ucz8K Pgo+IFRva2UsIHdoYXQgZWxzZSB3b3VsZCB5b3UgbGlrZSB0byBzZWUgZXZhbHVhdGVkPwo+Cj4g SSBnZW5lcmFsbHkgd2FudCB0byBzZWUgdGhyZWUgdGhpbmdzIG1lYXN1cmVkIHdoZW4gImJlbmNo bWFya2luZyIKPiB0ZWNobm9sb2dpZXM6IHRocm91Z2hwdXQsIGxhdGVuY3ksIGNwdSB1dGlsaXph dGlvbgo+IFdlJ3ZlIGNvdmVyZWQgdGhvc2UgdGhyZWUgSSB0aGluayAicmVhc29uYWJseSIuCgpI bW0sIGdvaW5nIGJhY2sgYW5kIGxvb2tpbmcgYXQgdGhpcyAoSSdkIGNvbXBsZXRlbHkgZm9yZ290 dGVuIGFib3V0IHRoaXMKcGF0Y2gpLCBJIHRoaW5rIEkgaGFkIHR3byBtYWluIGNvbmNlcm5zOgoK MS4gV2hhdCBoYXBwZW5zIGluIGEgZGVncmFkZWQgc2lnbmFsIHNpdHVhdGlvbiwgd2hlcmUgdGhl IHRocm91Z2hwdXQgaXMKICAgbGltaXRlZCBieSB0aGUgc2lnbmFsIGNvbmRpdGlvbnMsIG9yIGJ5 IGNvbnRlbnRpb24gd2l0aCBvdGhlciBkZXZpY2VzLgogICBCb3RoIG9mIHRoZXNlIGhhcHBlbiBy ZWd1bGFybHksIGFuZCBJIHdvcnJ5IHRoYXQgbGF0ZW5jeSB3aWxsIGJlCiAgIGJhZGx5IGFmZmVj dGVkIHVuZGVyIHRob3NlIGNvbmRpdGlvbnMuCgoyLiBXaGF0IGhhcHBlbnMgd2l0aCBvbGQgaGFy ZHdhcmUgdGhhdCBoYXMgd29yc2UgYnVmZmVyIG1hbmFnZW1lbnQgaW4KICAgdGhlIGRyaXZlci0+ ZmlybXdhcmUgcGF0aCAoZXNwZWNpYWxseSBkcml2ZXJzIHdpdGhvdXQgcHVzaC9wdWxsIG1vZGUK ICAgc3VwcG9ydCk/IEZvciB0aGVzZSwgdGhlIGxvd2VyLWxldmVsIHF1ZXVlaW5nIHN0cnVjdHVy ZSBpcyBsZXNzCiAgIGVmZmVjdGl2ZSBhdCBjb250cm9sbGluZyBxdWV1ZWluZyBsYXRlbmN5LgoK R2V0dGluZyB0aGUgcXVldWUgc2l6ZSBsaW1pdCBwYXRjaGVzIGZyb20gQ2hyb21lT1MgcG9ydGVk IHdvdWxkCmFsbGV2aWF0ZSBwb2ludCAyLiBJIGRvIGJlbGlldmUgS2FuIHNhaWQgaGUnZCBsb29r IGludG8gdGhhdCBvbmNlIHRoZQphaXJ0aW1lIHBhdGNoZXMgd2VyZSBtZXJnZWQuIFNvIEthbiwg YW55IHByb2dyZXNzIG9uIHRoYXQgZnJvbnQ/IDopCgo+IFdoYXQgZG9lcyBhICI0eCBpbmNyZWFz ZSBpbiBtZW1vcnkiIG1lYW4gaGVyZT8gV2VuLCBob3cgbXVjaCBtb3JlCj4gbWVtb3J5IGRvZXMg dGhpcyBjYXVzZSBhdGgxMGsgdG8gdXNlPwoKSSBkaWRuJ3Qgc2F5ICJtZW1vcnkiLCBJIHNhaWQg ImJ1ZmZlciBzaXplIi4uLiA6KQpJLmUuLCBpdCdzIHRoZSBsYXRlbmN5IGltcGFjdCBvZiB0aGUg aW5jcmVhc2VkIGJ1ZmZlcmluZyBJJ20gd29ycmllZAphYm91dCAoc2VlIGFib3ZlKSwgbm90IHRo ZSBzeXN0ZW0gbWVtb3J5IHVzYWdlLgoKLVRva2UKCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCmF0aDEwayBtYWlsaW5nIGxpc3QKYXRoMTBrQGxpc3RzLmlu ZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9h dGgxMGsK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 00ED5C43381 for ; Thu, 21 Feb 2019 15:43:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BF8C120823 for ; Thu, 21 Feb 2019 15:43:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=toke.dk header.i=@toke.dk header.b="kN8JXnHB" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726359AbfBUPnA (ORCPT ); Thu, 21 Feb 2019 10:43:00 -0500 Received: from mail.toke.dk ([52.28.52.200]:54309 "EHLO mail.toke.dk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725858AbfBUPm7 (ORCPT ); Thu, 21 Feb 2019 10:42:59 -0500 From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1550763777; bh=doaz1XB0TUc9c1ENlxALGOQFvxjfF+zYyZMvP62z2CE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=kN8JXnHBaw7nEuC82cV6dftzgZNhngmJfsMjM8Su8caRaUKGzy5HxeBFHGgtFrKga ctDQNjwcOrryPEUPe3befoGH2sydZrgR4gaCUeRv7jH4sVXvHUcSQxFtzhdyTR/x/u RKRUnMy0aTc/qiDXRkvsqN+bXTsAbFOhsbLf3Mtyl9Dp5M1lHb8GqSNqdxEA0MQC+Z B1RC2wFsdITIoCK/Ol3/9PqymzMEgKN8nV6nrcXKz91MXJe39WaNVnQ5SZuW39KdA5 Gbq9AV0HiBjECxPJ1C34+u1ojYQufroWPTU0t8iWsnaljpXTdpDc5WkMCdJ7oQXDZ2 kQvkfDMj64oMw== To: Grant Grundler , Kan Yan Cc: Johannes Berg , wgong@qti.qualcomm.com, wgong@codeaurora.org, ath10k@lists.infradead.org, linux-wireless@vger.kernel.org Subject: Re: [PATCH v2 2/2] ath10k: Set sk_pacing_shift to 6 for 11AC WiFi chips In-Reply-To: References: <1533724802-30944-1-git-send-email-wgong@codeaurora.org> <1533724802-30944-3-git-send-email-wgong@codeaurora.org> <87sh3pdtpg.fsf@toke.dk> <87mutue4y8.fsf@toke.dk> <1535967508.3437.31.camel@sipsolutions.net> <87in3m25uu.fsf@toke.dk> <1535975240.3437.61.camel@sipsolutions.net> <878t4i1z74.fsf@toke.dk> <871sa7ylmi.fsf@toke.dk> Date: Thu, 21 Feb 2019 16:42:56 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87r2c1i1vj.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org Grant Grundler writes: > On Thu, Sep 6, 2018 at 3:18 AM Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> >> Grant Grundler writes: >> >> >> And, well, Grant's data is from a single test in a noisy >> >> environment where the time series graph shows that throughput is all = over >> >> the place for the duration of the test; so it's hard to draw solid >> >> conclusions from (for instance, for the 5-stream test, the average >> >> throughput for 6 is 331 and 379 Mbps for the two repetitions, and for= 7 >> >> it's 326 and 371 Mbps) . Unfortunately I don't have the same hardware >> >> used in this test, so I can't go verify it myself; so the only thing I >> >> can do is grumble about it here... :) >> > >> > It's a fair complaint and I agree with it. My counter argument is the >> > opposite is true too: most ideal benchmarks don't measure what most >> > users see. While the data wgong provided are way more noisy than I >> > like, my overall "confidence" in the "conclusion" I offered is still >> > positive. >> >> Right. I guess I would just prefer a slightly more comprehensive >> evaluation to base a 4x increase in buffer size on... > > Kalle, is this why you didn't accept this patch? Other reasons? > > Toke, what else would you like to see evaluated? > > I generally want to see three things measured when "benchmarking" > technologies: throughput, latency, cpu utilization > We've covered those three I think "reasonably". Hmm, going back and looking at this (I'd completely forgotten about this patch), I think I had two main concerns: 1. What happens in a degraded signal situation, where the throughput is limited by the signal conditions, or by contention with other devices. Both of these happen regularly, and I worry that latency will be badly affected under those conditions. 2. What happens with old hardware that has worse buffer management in the driver->firmware path (especially drivers without push/pull mode support)? For these, the lower-level queueing structure is less effective at controlling queueing latency. Getting the queue size limit patches from ChromeOS ported would alleviate point 2. I do believe Kan said he'd look into that once the airtime patches were merged. So Kan, any progress on that front? :) > What does a "4x increase in memory" mean here? Wen, how much more > memory does this cause ath10k to use? I didn't say "memory", I said "buffer size"... :) I.e., it's the latency impact of the increased buffering I'm worried about (see above), not the system memory usage. -Toke