Thanks for the tip! I will try with your numbers. Really appreciate your
help.
I will check later with cake. Is cake autotuning the target and interval?
Regards,
Rodrigo

El lun., 14 ene. 2019 a las 17:48, Jonathan Morton (<chromatix99@gmail.com>)
escribió:

> > On 14 Jan, 2019, at 6:17 pm, Rodrigo Alvarez Dominguez <
> rodroleon@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
>
>