This problem is also caused by some weaknesses in the Codel algorithm itself. With an unresponsive UDP flow, one would expect Codel to naturally drop packets from the rogue queue and maintain a queuing delay close to the target delay value. But it does not. If you were to do a simple simulation of a single queue Codel, with say a 10 Mbps link and a UDP flow at 20 Mbps, you will see queue delay oscillate between 5 milliseconds and 10+ seconds, over periods of ~30 seconds. There are ways to fix this, if there is interest in doing so.
Anil -----Original Message----- From: Eric Dumazet [mailto:[email protected]] Sent: Tuesday, May 03, 2016 9:36 AM To: Agarwal, Anil Cc: Dave Taht; Jonathan Morton; [email protected]; [email protected]; ath10k Subject: Re: [Codel] fq_codel_drop vs a udp flood On Tue, 2016-05-03 at 12:50 +0000, Agarwal, Anil wrote: > I should be more precise about the statement about the inaccuracy of the > algorithm. > Given that we dequeue packets in round robin manner, the maxqidx value > may, on occasions, point to a queue which is smaller than the largest queue > by up to one MTU. That is not true. Linux qdiscs (fq_codel being one of them) can carry big packets, up to 64KB in size. You can not assume GRO/GSO are disabled. We absolutely want them for high performance. There is no way fq_codel will track in real time the biggest flow 'just in case we have to drop packets at enqueue()' This is a conscious choice I made years ago. This patch will fix the performance issue and keep the normal operations fast. https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_617307_&d=CwICaQ&c=jcv3orpCsv7C4ly8-ubDob57ycZ4jvhoYZNDBA06fPk&r=FyvaklKYrHaSCPjbBTdviWIW9uSbnxdNSheSGz1Jvq4&m=N_VdDT2cMUULbApQu-u_8yTr5wEiA4JHvbCH9jtLHkY&s=5jpMb-Je0Et1TFi0a4L7TZKt7wAtsP5AJwn1x6wnq0w&e= _______________________________________________ Codel mailing list [email protected] https://lists.bufferbloat.net/listinfo/codel
