[Codel] Codel configuration

[Jonathan Morton]

> On 14 Jan, 2019, at 6:17 pm, Rodrigo Alvarez Dominguez <rodroleon at gmail.com> wrote:
> 
> Hi Jonathan
> Thanks for your quick answer. REally appreciate it!!!
> I wil try later the cake statement (is it the same as codel)?. I am starting with Codel. So I need to have a better understanding of codel.

Cake is a more advanced implementation of the same principles.  Its shaper is more accurate than HTB, and it's easier to configure correctly than the component qdiscs and filters you're currently using.

> Where client asks for a FTP file to server. Link between router-server has a 150MBit speed with a delay of 250 ms.
> Then link between client and router has 10 Mbit and the Codel algorithm. So I am checking the differences between having codel or not.
> Do you have an advice to have a good scenario for testing Codel properly? Or a document to know how the differences parameter can affect to the communication?
> In my scenario it seems it is better not having Codel.  See attached ClientFTPCodelNO-NO-NO (nocodel) versus ClientFtpCodel1000..
> where a Codel Algorithm of 1000 packets, 13 ms target and 100 interval is configured

First, and most importantly, you're measuring only throughput, while ignoring latency.  The primary benefit of any 'smart queue" is in reducing latency, preferably with the least practical impact on throughput.  Dumb FIFOs often induce latencies of several seconds when loaded.  The improvement is visible to the user as quicker response and better reliability of operation while the link is busy.  Here's a better test to try out:

	http://www.dslreports.com/speedtest

Second, your Codel parameters are too tight for the relatively long-latency path you're measuring.  You should set "interval" to your expected path latency (250ms) and "target" to about a tenth of that (25ms).  I would also advise against "noecn" and replace it with "ecn"; this will safely have no effect if you don't have ECN-enabled traffic, but reduces packet loss if you do.

Cake has an "rtt" parameter so you don't have to manually select a target and interval, and it unconditionally supports ECN.  Updating my earlier suggestion:

	tc qdisc replace dev r1-eth0 root handle 1: cake bandwidth 10000kbit besteffort flows rtt 250ms

Third, you should turn on ECN on your end-hosts if you can.  Most servers will respond with ECN traffic if requested, so search for instructions for enabling ECN on your own machine.

 - Jonathan Morton