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

> 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

_______________________________________________
Codel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/codel

Reply via email to