From: Sebastian Moeller <moeller0@gmx.de> To: David Lang <david@lang.hm>,Roman Yeryomin <leroi.lists@gmail.com> Cc: make-wifi-fast@lists.bufferbloat.net, ath10k <ath10k@lists.infradead.org>, "codel@lists.bufferbloat.net" <codel@lists.bufferbloat.net>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, OpenWrt Development List <openwrt-devel@lists.openwrt.org> 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 [thread overview] Message-ID: <1E11CBFE-1471-4ECC-8D34-9172B61D3F59@gmx.de> (raw) In-Reply-To: <alpine.DEB.2.02.1605160127430.1574@nftneq.ynat.uz> Hi David, On May 16, 2016 10:46:25 AM GMT+02:00, David Lang <david@lang.hm> wrote: >On Mon, 16 May 2016, Roman Yeryomin wrote: > >> On 16 May 2016 at 11:12, David Lang <david@lang.hm> wrote: >>> On Mon, 16 May 2016, Roman Yeryomin wrote: >>> >>>> On 6 May 2016 at 22:43, Dave Taht <dave.taht@gmail.com> wrote: >>>>> >>>>> On Fri, May 6, 2016 at 11:56 AM, Roman Yeryomin ><leroi.lists@gmail.com> >>>>> wrote: >>>>>> >>>>>> On 6 May 2016 at 21:43, Roman Yeryomin <leroi.lists@gmail.com> >wrote: >>>>>>> >>>>>>> On 6 May 2016 at 15:47, Jesper Dangaard Brouer ><brouer@redhat.com> >>>>>>> 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. _______________________________________________ Codel mailing list Codel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/codel
WARNING: multiple messages have this Message-ID (diff)
From: Sebastian Moeller <moeller0@gmx.de> To: David Lang <david@lang.hm>, Roman Yeryomin <leroi.lists@gmail.com> Cc: make-wifi-fast@lists.bufferbloat.net, Dave Taht <dave.taht@gmail.com>, ath10k <ath10k@lists.infradead.org>, "codel@lists.bufferbloat.net" <codel@lists.bufferbloat.net>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, OpenWrt Development List <openwrt-devel@lists.openwrt.org> Subject: Re: [OpenWrt-Devel] [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood) Date: Mon, 16 May 2016 12:34:24 +0200 [thread overview] Message-ID: <1E11CBFE-1471-4ECC-8D34-9172B61D3F59@gmx.de> (raw) In-Reply-To: <alpine.DEB.2.02.1605160127430.1574@nftneq.ynat.uz> Hi David, On May 16, 2016 10:46:25 AM GMT+02:00, David Lang <david@lang.hm> wrote: >On Mon, 16 May 2016, Roman Yeryomin wrote: > >> On 16 May 2016 at 11:12, David Lang <david@lang.hm> wrote: >>> On Mon, 16 May 2016, Roman Yeryomin wrote: >>> >>>> On 6 May 2016 at 22:43, Dave Taht <dave.taht@gmail.com> wrote: >>>>> >>>>> On Fri, May 6, 2016 at 11:56 AM, Roman Yeryomin ><leroi.lists@gmail.com> >>>>> wrote: >>>>>> >>>>>> On 6 May 2016 at 21:43, Roman Yeryomin <leroi.lists@gmail.com> >wrote: >>>>>>> >>>>>>> On 6 May 2016 at 15:47, Jesper Dangaard Brouer ><brouer@redhat.com> >>>>>>> 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
next prev parent reply other threads:[~2016-05-16 10:34 UTC|newest] Thread overview: 108+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-05-01 3:41 fq_codel_drop vs a udp flood Dave Taht 2016-05-01 4:46 ` [Make-wifi-fast] " Jonathan Morton 2016-05-01 5:08 ` Ben Greear 2016-05-01 5:23 ` Dave Taht 2016-05-01 14:47 ` [Make-wifi-fast] " dpreed 2016-05-02 14:03 ` Roman Yeryomin 2016-05-02 18:40 ` Dave Taht 2016-05-05 13:55 ` Roman Yeryomin 2016-05-05 14:55 ` Roman Yeryomin 2016-05-02 19:47 ` David Lang 2016-05-01 17:59 ` [Codel] " Eric Dumazet 2016-05-01 18:20 ` Jonathan Morton 2016-05-01 18:46 ` Eric Dumazet 2016-05-01 19:55 ` Eric Dumazet 2016-05-02 7:47 ` Jesper Dangaard Brouer 2016-05-01 20:35 ` Jonathan Morton 2016-05-01 20:55 ` Eric Dumazet 2016-05-02 14:18 ` Roman Yeryomin 2016-05-02 15:07 ` Eric Dumazet 2016-05-02 15:43 ` Roman Yeryomin 2016-05-02 16:14 ` Eric Dumazet 2016-05-02 17:08 ` Dave Taht 2016-05-02 17:44 ` Eric Dumazet 2016-05-05 14:32 ` Roman Yeryomin 2016-05-05 14:53 ` Roman Yeryomin 2016-05-05 15:32 ` Dave Taht 2016-05-05 16:07 ` Roman Yeryomin 2016-05-05 16:59 ` Jonathan Morton 2016-05-05 17:39 ` Roman Yeryomin 2016-05-05 18:16 ` Dave Taht 2016-05-05 18:33 ` Dave Taht 2016-05-05 16:12 ` Eric Dumazet 2016-05-05 16:25 ` Roman Yeryomin 2016-05-05 16:42 ` Roman Yeryomin 2016-05-06 10:55 ` Roman Yeryomin 2016-05-05 19:23 ` Eric Dumazet 2016-05-05 19:41 ` Dave Taht 2016-05-06 8:41 ` moeller0 2016-05-06 11:33 ` Jesper Dangaard Brouer 2016-05-06 11:46 ` moeller0 2016-05-06 13:25 ` Eric Dumazet 2016-05-06 15:25 ` moeller0 2016-05-06 15:58 ` Eric Dumazet 2016-05-06 16:30 ` moeller0 2016-05-06 15:55 ` [PATCH net-next] fq_codel: add memory limitation per queue Eric Dumazet 2016-05-09 3:49 ` David Miller 2016-05-09 4:14 ` Cong Wang 2016-05-09 4:31 ` Eric Dumazet 2016-05-09 5:07 ` Cong Wang 2016-05-09 14:26 ` Eric Dumazet 2016-05-10 4:34 ` Cong Wang 2016-05-10 4:45 ` Eric Dumazet 2016-05-10 4:57 ` Cong Wang 2016-05-10 5:10 ` Eric Dumazet 2016-05-16 1:16 ` [PATCH net-next] fq_codel: fix memory limitation drift Eric Dumazet 2016-05-17 1:57 ` David Miller 2016-05-06 9:42 ` OpenWRT wrong adjustment of fq_codel defaults (Was: fq_codel_drop vs a udp flood) Jesper Dangaard Brouer 2016-05-06 9:42 ` OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] " Jesper Dangaard Brouer 2016-05-06 12:47 ` OpenWRT wrong adjustment of fq_codel defaults (Was: " Jesper Dangaard Brouer 2016-05-06 12:47 ` OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] " Jesper Dangaard Brouer 2016-05-06 18:43 ` OpenWRT wrong adjustment of fq_codel defaults (Was: " Roman Yeryomin 2016-05-06 18:43 ` OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] " Roman Yeryomin 2016-05-06 18:56 ` OpenWRT wrong adjustment of fq_codel defaults (Was: " Roman Yeryomin 2016-05-06 18:56 ` OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] " Roman Yeryomin 2016-05-06 19:43 ` OpenWRT wrong adjustment of fq_codel defaults (Was: " Dave Taht 2016-05-06 19:43 ` OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] " Dave Taht 2016-05-15 22:34 ` OpenWRT wrong adjustment of fq_codel defaults (Was: " Roman Yeryomin 2016-05-15 22:34 ` OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] " Roman Yeryomin 2016-05-15 23:07 ` OpenWRT wrong adjustment of fq_codel defaults (Was: " Eric Dumazet 2016-05-15 23:07 ` OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] " Eric Dumazet 2016-05-15 23:27 ` OpenWRT wrong adjustment of fq_codel defaults (Was: " Roman Yeryomin 2016-05-15 23:27 ` OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] " Roman Yeryomin 2016-05-16 8:12 ` [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: " David Lang 2016-05-16 8:12 ` [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] " David Lang 2016-05-16 8:26 ` Roman Yeryomin 2016-05-16 8:26 ` Roman Yeryomin 2016-05-16 8:46 ` [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: " David Lang 2016-05-16 8:46 ` [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] " David Lang 2016-05-16 10:34 ` Sebastian Moeller [this message] 2016-05-16 10:34 ` [OpenWrt-Devel] " Sebastian Moeller 2016-05-16 8:14 ` OpenWRT wrong adjustment of fq_codel defaults (Was: " Roman Yeryomin 2016-05-16 8:14 ` OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] " Roman Yeryomin 2016-05-16 14:23 ` [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: " Eric Dumazet 2016-05-16 14:23 ` [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] " Eric Dumazet 2016-05-16 16:04 ` Dave Taht 2016-05-16 16:04 ` Dave Taht 2016-05-16 19:46 ` OpenWRT wrong adjustment of fq_codel defaults (Was: " Roman Yeryomin 2016-05-16 19:46 ` OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] " Roman Yeryomin 2016-05-07 9:57 ` Kevin Darbyshire-Bryant 2016-05-15 22:47 ` Roman Yeryomin 2016-05-15 22:47 ` Roman Yeryomin 2016-05-03 2:26 ` [Codel] fq_codel_drop vs a udp flood Dave Taht 2016-05-03 5:21 ` Dave Taht 2016-05-03 12:39 ` Agarwal, Anil 2016-05-03 12:50 ` Agarwal, Anil 2016-05-03 13:35 ` Eric Dumazet 2016-05-03 15:37 ` Agarwal, Anil 2016-05-03 17:37 ` Dave Taht 2016-05-03 17:54 ` Eric Dumazet 2016-05-03 18:11 ` Dave Taht 2016-05-03 13:20 ` Kevin Darbyshire-Bryant 2016-05-01 18:26 ` Dave Taht 2016-05-01 22:30 ` Eric Dumazet 2016-05-02 14:09 ` Roman Yeryomin 2016-05-02 15:04 ` Eric Dumazet 2016-05-02 15:42 ` Roman Yeryomin 2016-05-02 13:47 ` [Make-wifi-fast] " Roman Yeryomin 2016-05-02 15:01 ` Eric Dumazet
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1E11CBFE-1471-4ECC-8D34-9172B61D3F59@gmx.de \ --to=moeller0@gmx.de \ --cc=ath10k@lists.infradead.org \ --cc=codel@lists.bufferbloat.net \ --cc=david@lang.hm \ --cc=leroi.lists@gmail.com \ --cc=make-wifi-fast@lists.bufferbloat.net \ --cc=netdev@vger.kernel.org \ --cc=openwrt-devel@lists.openwrt.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.