Re: [OpenWrt-Devel] [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood)

[Sebastian Moeller]

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.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood)

[David Lang]

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.


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

Re: [OpenWrt-Devel] [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood)

[Roman Yeryomin]

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).

Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood)

[David Lang]

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.


David Lang
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel