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

[Dave Taht]

On Thu, May 5, 2016 at 9:59 AM, 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.

I could see an AQM dropper testing to see if it is dropping a frag,
and then dropping any further fragments, also. We're looking at the IP
headers anyway in that section of the code, and the decision to drop
is (usually) rare, and fragments a PITA.

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



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org