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

[Roman Yeryomin]

On 5 May 2016 at 19:59, Jonathan Morton <chromatix99 at gmail.com> wrote:
>> Having same (low) speeds.
>> So it didn't help at all :(
>
> Although the new “emergency drop” code is now dropping batches of consecutive packets, Codel is also still dropping individual packets in between these batches, probably at a high rate.  Since all fragments of an original packet are required to reassemble it, but Codel doesn’t link related fragments when deciding to drop, each fragment lost in this way reduces throughput efficiency.  Only a fraction of the original packets can be reassembled correctly, but the surviving (yet useless) fragments still occupy link capacity.
>
> This phenomenon is not Codel specific; I would also expect to see it on most other AQMs, and definitely on RED variants, including PIE.  Fortunately for real traffic, it normally arises only on artificial traffic such as iperf runs with large UDP packets.  Unfortunately for AQM advocates, iperf uses large UDP packets by default, and it is very easy to misinterpret the results unfavourably for AQM (as opposed to unfavourably for iperf).
>
> If you re-run the test with iperf set to a packet size compatible with the path MTU, you should see much better throughput numbers due to the elimination of fragmented packets.  A UDP payload size of 1280 bytes is a safe, conservative figure for a normal MTU in the vicinity of 1500.

Setting packet size to 1280 (-l1280) instead of 1472, I got even lower
speed (18-20Mbps).
Other ideas?

>> Limit of 1024 packets and 1024 flows is not wise I think.
>>
>> (If all buckets are in use, each bucket has a virtual queue of 1 packet,
>> which is almost the same than having no queue at all)
>
> This, while theoretically important in extreme cases with very large numbers of flows, is not relevant to the specific test in question.
>
>  - Jonathan Morton
>