All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dennis Jacobfeuerborn <dennisml@conversis.de>
To: lartc@vger.kernel.org
Subject: Re: Good qdisc for routers?
Date: Tue, 05 Nov 2013 21:35:22 +0000	[thread overview]
Message-ID: <5279649A.9070909@conversis.de> (raw)
In-Reply-To: <5279134B.6070207@conversis.de>

Hi Remy,
from what I understand the default pfifo_fast qdisc isn't particulary 
fair when a single flow or a few flows flood the interface/buffer with 
packets so I am wondering if qdiscs like QFQ, SFQ or CHOKe could be 
improvements compared to the default "dumb" pfifo one.

Regards,
   Dennis

On 05.11.2013 20:33, Remy Mudingay wrote:
> Hi Dennis,
>
> I read the same article but since it mentioned datacenter I understood this to not apply to Internet bound traffic. However even on a gigabit WAN link codel (in my case fq_codel) could improve the responsiveness of competing flows. A few open source distributions (openwrt,dd-wrt and gargoyle).
>
> By the way, why do you want to move away from the default qdisc?
>
> Cheers,
>
> Remy.
>
> Sent from my iPhone
>
>> On Nov 5, 2013, at 19:42, Dennis Jacobfeuerborn <dennisml@conversis.de> wrote:
>>
>>> On 05.11.2013 19:06, Remy Mudingay wrote:
>>> Hi Dennis,
>>>
>>> I  highly recommend trying out codel or fq_codel. I've been using
>>> fq_codel for well over a year now. I have just over a thousand users
>>> going through the router. I use it mainly because I wanted in-queue
>>> packet delays statistics but I didn't switch from pfifo_fast because of
>>> any perceived problems.
>>> Anyway, You won't need to patch your current Linux install as long as
>>> it's version 3.3 or higher.
>>>
>>> I use the following two lines for each interface.
>>>
>>> tc qdisc add dev eth0 root handle 1: fq_codel quantum 1514 flows 1024 noecn
>>> tc filter add dev eth0 prio 1 protocol all parent 1: handle 1 flow hash
>>> keys nfct-src,nfct-dst,nfct-proto,nfct-proto-src,nfct-proto-dst divisor
>>> 10242 perturb 300 baseclass 1:1
>>>
>>> You can get more in depth information from here
>>> http://www.bufferbloat.net/projects/codel/wiki.
>>
>> Codel seems more geared towards low latency. The following statement from the wiki doesn't make it sound like this is the right choice here:
>>
>> "People have tried to run CoDel in very big routers, with hundreds of simultaneous flows, a situation not simulated in advance. There, it isn't controlling the queue the way it should: whether this is a problem with the algorithm, or the implementation, is not yet understood.
>>
>> It is clear that unmodified, CoDel is not appropriate for AQM of traffic inside a data center; it does not react in a timely enough fashion. Whether the modifications of the ideas in CoDel will solve this problem is not yet known. Again, this is an area which CoDel was not designed to solve or it simulated in before publication."
>>
>> Regards,
>>   Dennis


  parent reply	other threads:[~2013-11-05 21:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-05 15:48 Good qdisc for routers? Dennis Jacobfeuerborn
2013-11-05 18:42 ` Dennis Jacobfeuerborn
2013-11-05 19:33 ` Remy Mudingay
2013-11-05 21:35 ` Dennis Jacobfeuerborn [this message]
2013-11-06 11:22 ` Nicolas Sebrecht
2014-01-02 23:00 ` Dave Taht

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5279649A.9070909@conversis.de \
    --to=dennisml@conversis.de \
    --cc=lartc@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.