Re: [Codel] [Make-wifi-fast] fq_codel_drop vs a udp flood

2016-05-02 Thread Isaac Konikoff
Here are two similar test results with TCP download throughput over the air using ch149 ht80 to a Netgear R7000 AP. Lanforge TCP download test with 1 station downloading for 1 minute up to 10 stations. Flent test with 1 station using the tcp_download test to a netserver running on the eth1

Re: [Codel] [Make-wifi-fast] fq_codel_drop vs a udp flood

2016-05-02 Thread David Lang
On Mon, 2 May 2016, Roman Yeryomin wrote: On 1 May 2016 at 17:47, wrote: Maybe I missed something, but why is it important to optimize for a UDP flood? We don't need to optimize it to UDP but UDP is used e.g. by torrents to achieve higher throughput and used a lot in

Re: [Codel] [Make-wifi-fast] fq_codel_drop vs a udp flood

2016-05-02 Thread Dave Taht
On Mon, May 2, 2016 at 7:03 AM, Roman Yeryomin wrote: > On 1 May 2016 at 17:47, wrote: >> Maybe I missed something, but why is it important to optimize for a UDP >> flood? > > We don't need to optimize it to UDP but UDP is used e.g. by torrents > to

Re: [Codel] [Make-wifi-fast] fq_codel_drop vs a udp flood

2016-05-02 Thread Eric Dumazet
On Mon, 2016-05-02 at 16:47 +0300, Roman Yeryomin wrote: > So it looks to me that fq_codel is just broken if it needs half of my > resources. Agreed. When I wrote fq_codel, I was not expecting that one UDP socket could fill fq_codel with packets, since we have standard backpressure. SO_SNDBUF

Re: [Codel] [Make-wifi-fast] fq_codel_drop vs a udp flood

2016-05-01 Thread dpreed
Maybe I missed something, but why is it important to optimize for a UDP flood? A general observation of control theory is that there is almost always an adversarial strategy that will destroy any control regime. Sometimes one has to invoke an "oracle" that knows the state of the control system