[Make-wifi-fast] fq_codel_drop vs a udp flood

[Roman Yeryomin]

On 5 May 2016 at 16:55, Roman Yeryomin <leroi.lists at gmail.com> wrote:
> On 2 May 2016 at 21:40, Dave Taht <dave.taht at gmail.com> wrote:
>> On Mon, May 2, 2016 at 7:03 AM, Roman Yeryomin <leroi.lists at gmail.com> wrote:
>>> On 1 May 2016 at 17:47,  <dpreed at reed.com> 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 general.
>>
>> Torrents use uTP congestion control and won't hit this function at
>> all. And eric just made fq_codel_drop more efficient for tests that
>> do.
>>
>> There are potentially zillions of other issues with ampdu's, txop
>> usage, aggregate "packing", etc that can also affect and other
>> protocools.
>>
>>> And, again, in this case TCP is broken too (750Mbps down to 550), so
>>> it's not like Dave is saying that UDP test is broken, fq_codel is just
>>> too hungry for CPU
>>
>> "fq_codel_drop" was too hungry for cpu. fixed. thx eric. :)
>>
>> I've never seen ath10k tcp throughput in the real world (e.g not wired
>> up, over the air) even close to 750 under test on the ath10k (I've
>> seen 300, and I'm getting some better gear up this week)... and
>> everybody tests wifi differently.
>
> perhaps you didn't have 3x3 client and AP?
>
>> (for the record, what was your iperf tcp test line?). More people
>> testing differently = good.
>
> iperf3 -c <server_ip> -t600

actually `iperf3 -c <server_ip> -t600 -R` for download, client POV