From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sebastian Moeller Subject: Re: [OpenWrt-Devel] [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: fq_codel_drop vs a udp flood) Date: Mon, 16 May 2016 12:34:24 +0200 Message-ID: <1E11CBFE-1471-4ECC-8D34-9172B61D3F59@gmx.de> References: <1462205669.5535.254.camel@edumazet-glaptop3.roam.corp.google.com> <1462464776.13075.18.camel@edumazet-glaptop3.roam.corp.google.com> <1462476207.13075.20.camel@edumazet-glaptop3.roam.corp.google.com> <20160506114243.4eb4f95e@redhat.com> <20160506144740.210901f5@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: make-wifi-fast@lists.bufferbloat.net, ath10k , "codel@lists.bufferbloat.net" , "netdev@vger.kernel.org" , OpenWrt Development List To: David Lang ,Roman Yeryomin Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: codel-bounces@lists.bufferbloat.net Sender: "Codel" List-Id: netdev.vger.kernel.org SGkgRGF2aWQsCgpPbiBNYXkgMTYsIDIwMTYgMTA6NDY6MjUgQU0gR01UKzAyOjAwLCBEYXZpZCBM YW5nIDxkYXZpZEBsYW5nLmhtPiB3cm90ZToKPk9uIE1vbiwgMTYgTWF5IDIwMTYsIFJvbWFuIFll cnlvbWluIHdyb3RlOgo+Cj4+IE9uIDE2IE1heSAyMDE2IGF0IDExOjEyLCBEYXZpZCBMYW5nIDxk YXZpZEBsYW5nLmhtPiB3cm90ZToKPj4+IE9uIE1vbiwgMTYgTWF5IDIwMTYsIFJvbWFuIFllcnlv bWluIHdyb3RlOgo+Pj4KPj4+PiBPbiA2IE1heSAyMDE2IGF0IDIyOjQzLCBEYXZlIFRhaHQgPGRh dmUudGFodEBnbWFpbC5jb20+IHdyb3RlOgo+Pj4+Pgo+Pj4+PiBPbiBGcmksIE1heSA2LCAyMDE2 IGF0IDExOjU2IEFNLCBSb21hbiBZZXJ5b21pbgo+PGxlcm9pLmxpc3RzQGdtYWlsLmNvbT4KPj4+ Pj4gd3JvdGU6Cj4+Pj4+Pgo+Pj4+Pj4gT24gNiBNYXkgMjAxNiBhdCAyMTo0MywgUm9tYW4gWWVy eW9taW4gPGxlcm9pLmxpc3RzQGdtYWlsLmNvbT4KPndyb3RlOgo+Pj4+Pj4+Cj4+Pj4+Pj4gT24g NiBNYXkgMjAxNiBhdCAxNTo0NywgSmVzcGVyIERhbmdhYXJkIEJyb3Vlcgo+PGJyb3VlckByZWRo YXQuY29tPgo+Pj4+Pj4+IHdyb3RlOgo+Pj4+Pj4+Pgo+Pj4+Pj4+Pgo+Pj4+Cj4+Pj4+IFRoYXQg aXMgdG9vIGxvdyBhIGxpbWl0LCBhbHNvLCBmb3Igbm9ybWFsIHVzZS4gQW5kOgo+Pj4+PiBmb3Ig dGhlIHB1cnBvc2Ugb2YgdGhpcyBwYXJ0aWN1bGFyIFVEUCB0ZXN0LCBmbG93cyAxNiBpcyBvaywg YnV0Cj5ub3QKPj4+Pj4gaWRlYWwuCj4+Pj4KPj4+Pgo+Pj4+IEkgcGxheWVkIHdpdGggZGlmZmVy ZW50IGNvbWJpbmF0aW9ucywgaXQgZG9lc24ndCBtYWtlIGFueQo+Pj4+IChzaWduaWZpY2FudCkg ZGlmZmVyZW5jZTogMjAtMzBNYnBzLCBub3QgbW9yZS4KPj4+PiBXaGF0IG51bWJlcnMgd291bGQg eW91IHByb3Bvc2U/Cj4+Pgo+Pj4KPj4+IEhvdyBtYW55IGRpZmZlcmVudCBmbG93cyBkaWQgeW91 IGhhdmUgZ29pbmcgYXQgb25jZT8gSSBiZWxpZXZlIHRoYXQKPnRoZQo+Pj4gcmVhc29uIGZvciBo aWdoZXIgbnVtYmVycyBpc24ndCBmb3IgdGhyb3VnaHB1dCwgYnV0IHRvIGFsbG93IGZvcgo+bW9y ZSBmbG93cwo+Pj4gdG8gYmUgaXNvbGF0ZWQgZnJvbSBlYWNoIG90aGVyLiBJZiB5b3UgaGF2ZSB0 b28gZmV3IGJ1Y2tldHMsCj5kaWZmZXJlbnQgZmxvd3MKPj4+IHdpbGwgZW5kIHVwIGJlaW5nIGNv bWJpbmVkIGludG8gb25lIGJ1Y2tldCBzbyB0aGF0IG9uZSB3aWxsIGFmZmVjdAo+dGhlIG90aGVy Cj4+PiBtb3JlLgo+Pgo+PiBJJ20gdGVzdGluZyB3aXRoIG9uZSBmbG93LCBJIG5ldmVyIHNhdyBi aWdnZXIgcGVyZm9ybWFuY2Ugd2l0aCBtb3JlCj4+IGZsb3dzIChlLmcuIC1QOCB0byBpcGVyZjMp Lgo+Cj5UaGUgaXNzdWUgaXNuJ3QgcGVyZm9ybWFuY2UsIGl0J3MgaXNvbGF0aW5nIGEgRE5TIHJl cXVlc3QgZnJvbSBhIFZvSVAKPmZsb3cgCj5mcm9tIGEgc3RyZWFtaW5nIHZpZGVvIGZsb3cgZnJv bSBhIERWRCBpbWFnZSBkb3dubG9hZC4KPgo+VGhlIHF1ZXN0aW9uIGlzIGhvdyBtYW55IGJ1Y2tl dHMgZG8geW91IG5lZWQgdG8gaGF2ZSB0byBpc29sYXRlIHRoZXNlCj5pbiAKPnByYWN0aWNlPyBp dCBkZXBlbmRzIGhvdyBtYW55IGZsb3dzIHlvdSBoYXZlLiBUaGUgZGVmYXVsdCB3YXMgMTAyNAo+ YnVja2V0cywgYnV0IAo+Z290IGNoYW5nZWQgdG8gMTI4IGZvciBsb3cgbWVtb3J5IGRldmljZXMs IGFuZCB0aGF0IGxvd2VyIHZhbHVlIGdvdAo+bWFkZSBpbnRvIAo+dGhlIGRlZmF1bHQsIGV2ZW4g Zm9yIGRldmljZXMgd2l0aCBsb3RzIG9mIG1lbW9yeS4KCkFuZCBJIGJlbGlldmUgdGhhdCB0aGUg cmVkdWN0aW9uIHdhcyBzdWJvcHRpbWFsLCB3ZSBuZWVkIHRoZSBIYXNoIGJ1Y2tldHMgdG8gc3By ZWFkIHRoZSBnbG93cyBhcm91bmQgdG8gYXZvaWQgc2hhcmVkIGZhdGUgZHVlIHRvIHNoYXJlZCBi dWNrZXRzLi4uIFNvIHRoZSAxMDI0IGdsb3dzIG1ha2UgYSBsb3Qgb2Ygc2Vuc2UgZXZlbiBpZiB0 aGUgbnVtYmVyIG9mIHJlYWwgIGNvbmN1cnJlbnQgZmxvd3MgaXMgbG93ZXIgdGhpbmsgYmlydGhk YXkgcGFyYWRveG9uLgpUaGUgY2hhbmdlIGNhbWUgYmVjYXVzZSBhdCBmdWxsIHNhdHVyYXRpb24g b3VyIHJlZHVjZWQgcGFja2V0IGxpbWl0IG9ubHkgYWxsb3dlZCBvbmUgcGFja2V0IHBlciBidWNr ZXQgd2hpY2ggaXMgdG9vIGxvdyBmb3IgZGVjZW50IHBlcmZvcm1hbmNlLi4uIGFsc28gbGVzcyBo YXNoIGJ1Y2tldHMgbWFrZSBzZWFyY2hpbmcgZmFzdGVyLgpTaW5jZSB3ZSBub3cgY2FuIHNwZWNp ZnkgYSBtZW1vcnkgbGltaXQgaW4gYWRkaXRpb24gdG8gdGhlIHBhY2tldCBsaW1pdCwgd2Ugc2hv dWxkIHNldCB0aGUgcGFja2V0IGxpbWl0IGJhY2sgdG8gaXRzIGRlZmF1bHQgb2YgMTAyNDAgYW5k IGluc3RlYWQgc2V0IHRoZSBtZW1vcnkgbGltaXQgdG8gc29tZXRoaW5nIHNhbWUgZm9yIGVhY2gg cGxhdGZvcm0uIFRoaXMgd2lsbCBlZmZlY3RpdmVseSBoYXZlIHRoZSBzYW1lIGNvbnNlcXVlbmNl cyBhcyBzZXR0aW5nIGEgcGFja2V0IGxpbWl0LCBleGNlcHQgaXQgYmVjb21lcyBjbGVhcmVyIHdo eSBwZXJmb3JtYW5jZSBkZWdyYWRlcyBhbmQgSSBhdCBsZWFzdCB0YWtlIGEgcGVyZm9ybWFuY2Ug aGl0IGdsYWRseSBvdmVyIGEgZm9yY2VkIG9vbSByZWJvb3QuLi4uCgoKCj4KPkknbSB3b25kZXJp bmcgaWYgaW5zdGVhZCBvZiB0cnlpbmcgdG8gc2l6ZSB0aGlzIGJhc2VkIG9uIGRldmljZSBtZW1v cnksCj5jYW4gaXQgCj5iZSByZXNpemFibGUgb24gdGhlIGZseSBhbmQgZ3JvdyBpZiB0b28gbWFu eSBmbG93cy9jb2xsaXNpb25zIGFyZQo+ZGV0ZWN0ZWQ/Cj4KPkRhdmlkIExhbmcKPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj5vcGVud3J0LWRldmVsIG1h aWxpbmcgbGlzdAo+b3BlbndydC1kZXZlbEBsaXN0cy5vcGVud3J0Lm9yZwo+aHR0cHM6Ly9saXN0 cy5vcGVud3J0Lm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vb3BlbndydC1kZXZlbAoKLS0g ClNlbnQgZnJvbSBteSBBbmRyb2lkIGRldmljZSB3aXRoIEstOSBNYWlsLiBQbGVhc2UgZXhjdXNl IG15IGJyZXZpdHkuCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCkNvZGVsIG1haWxpbmcgbGlzdApDb2RlbEBsaXN0cy5idWZmZXJibG9hdC5uZXQKaHR0cHM6 Ly9saXN0cy5idWZmZXJibG9hdC5uZXQvbGlzdGluZm8vY29kZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mout.gmx.net ([212.227.17.20]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1b2Frl-0004Ha-A7 for ath10k@lists.infradead.org; Mon, 16 May 2016 10:35:19 +0000 In-Reply-To: References: <1462205669.5535.254.camel@edumazet-glaptop3.roam.corp.google.com> <1462464776.13075.18.camel@edumazet-glaptop3.roam.corp.google.com> <1462476207.13075.20.camel@edumazet-glaptop3.roam.corp.google.com> <20160506114243.4eb4f95e@redhat.com> <20160506144740.210901f5@redhat.com> MIME-Version: 1.0 Subject: Re: [OpenWrt-Devel] [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood) From: Sebastian Moeller Date: Mon, 16 May 2016 12:34:24 +0200 Message-ID: <1E11CBFE-1471-4ECC-8D34-9172B61D3F59@gmx.de> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "ath10k" Errors-To: ath10k-bounces+kvalo=adurom.com@lists.infradead.org To: David Lang , Roman Yeryomin Cc: make-wifi-fast@lists.bufferbloat.net, Dave Taht , ath10k , "codel@lists.bufferbloat.net" , "netdev@vger.kernel.org" , OpenWrt Development List Hi David, On May 16, 2016 10:46:25 AM GMT+02:00, David Lang wrote: >On Mon, 16 May 2016, Roman Yeryomin wrote: > >> On 16 May 2016 at 11:12, David Lang wrote: >>> On Mon, 16 May 2016, Roman Yeryomin wrote: >>> >>>> On 6 May 2016 at 22:43, Dave Taht wrote: >>>>> >>>>> On Fri, May 6, 2016 at 11:56 AM, Roman Yeryomin > >>>>> wrote: >>>>>> >>>>>> On 6 May 2016 at 21:43, Roman Yeryomin >wrote: >>>>>>> >>>>>>> On 6 May 2016 at 15:47, Jesper Dangaard Brouer > >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>> >>>>> That is too low a limit, also, for normal use. And: >>>>> for the purpose of this particular UDP test, flows 16 is ok, but >not >>>>> ideal. >>>> >>>> >>>> I played with different combinations, it doesn't make any >>>> (significant) difference: 20-30Mbps, not more. >>>> What numbers would you propose? >>> >>> >>> How many different flows did you have going at once? I believe that >the >>> reason for higher numbers isn't for throughput, but to allow for >more flows >>> to be isolated from each other. If you have too few buckets, >different flows >>> will end up being combined into one bucket so that one will affect >the other >>> more. >> >> I'm testing with one flow, I never saw bigger performance with more >> flows (e.g. -P8 to iperf3). > >The issue isn't performance, it's isolating a DNS request from a VoIP >flow >from a streaming video flow from a DVD image download. > >The question is how many buckets do you need to have to isolate these >in >practice? it depends how many flows you have. The default was 1024 >buckets, but >got changed to 128 for low memory devices, and that lower value got >made into >the default, even for devices with lots of memory. And I believe that the reduction was suboptimal, we need the Hash buckets to spread the glows around to avoid shared fate due to shared buckets... So the 1024 glows make a lot of sense even if the number of real concurrent flows is lower think birthday paradoxon. The change came because at full saturation our reduced packet limit only allowed one packet per bucket which is too low for decent performance... also less hash buckets make searching faster. Since we now can specify a memory limit in addition to the packet limit, we should set the packet limit back to its default of 10240 and instead set the memory limit to something same for each platform. This will effectively have the same consequences as setting a packet limit, except it becomes clearer why performance degrades and I at least take a performance hit gladly over a forced oom reboot.... > >I'm wondering if instead of trying to size this based on device memory, >can it >be resizable on the fly and grow if too many flows/collisions are >detected? > >David Lang >_______________________________________________ >openwrt-devel mailing list >openwrt-devel@lists.openwrt.org >https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- Sent from my Android device with K-9 Mail. Please excuse my brevity. _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k