On 5 May 2016 at 19:59, Jonathan Morton <chromati...@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 > _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
