From: Jonathan Morton <chromatix99@gmail.com>
To: Rodrigo Alvarez Dominguez <rodroleon@gmail.com>
Cc: codel@lists.bufferbloat.net
Subject: Re: [Codel] Codel configuration
Date: Mon, 14 Jan 2019 18:48:16 +0200 [thread overview]
Message-ID: <9B8E2B07-BBDB-41A4-BA21-AB9B4CEFE075@gmail.com> (raw)
In-Reply-To: <CALFXYB+X2VAJ=5JdjNjuZLrNcoXsaSWOdGcZ98=gmfXokAnHdw@mail.gmail.com>
> 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
next prev parent reply other threads:[~2019-01-14 16:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-14 10:54 Rodrigo Alvarez Dominguez
2019-01-14 15:24 ` Jonathan Morton
2019-01-14 16:17 ` Rodrigo Alvarez Dominguez
2019-01-14 16:48 ` Jonathan Morton [this message]
2019-01-14 22:10 ` Rodrigo Alvarez Dominguez
2019-01-15 1:14 ` Jonathan Morton
2019-01-15 9:27 ` Rodrigo Alvarez Dominguez
2019-01-15 16:48 ` Jonathan Morton
-- strict thread matches above, loose matches on Subject: below --
2019-01-14 10:45 Rodrigo Alvarez Dominguez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/codel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9B8E2B07-BBDB-41A4-BA21-AB9B4CEFE075@gmail.com \
--to=chromatix99@gmail.com \
--cc=codel@lists.bufferbloat.net \
--cc=rodroleon@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox