All of lore.kernel.org
 help / color / mirror / Atom feed
From: Corey Hickey <bugfood-ml@fatooh.org>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Is ESFQ working?
Date: Sun, 11 Feb 2007 19:10:34 +0000	[thread overview]
Message-ID: <45CF6A2A.3050009@fatooh.org> (raw)
In-Reply-To: <200702111301.51685.alejandro_aero@yahoo.es>

Alejandro Lorenzo Gallego wrote:
> On Sunday 11 February 2007 16:48:10 Tomasz Chilinski wrote:
>> On Sun, 11 Feb 2007 16:19:54 +0100, Alejandro Lorenzo Gallego wrote
>>
>>>>> [cut]
>>>> Have u tried to replace CLASSIFY target by MARK target and then using
>>>> fw filter? I have got bad experience with CLASSIFY target.
>>> Behaviour is identical if i use classify or mark, however, i
>>> expected this, because the packets do go to the right classes, it's
>>> just it looks that ESFQ is not assuring fairness between users
>> Which version of ESFQ? Patch for 2.6.15.1 or 2.6.19.2?
>>
>> Bests, Tomasz Chilinski.
>>
> 
> Actually for 2.6.29.2 

I assume that's a typo and you mean '2.6.19.2'.

> And i made some progress, using a depth parameter higher than default (800) it 
> behaves better and closer to fairness.... 

The default for depth is only 128. You're hashing by dst, right? On your
network, how many destinations will be receiving packets concurrently?
In other words, how many of your users will be downloading at the same time?

> ¿Can some explain the exact meaning of limit and depth options?

I am 95% sure of the following, which isn't in the ESFQ documentation
yet because I just recently read the relevant paperwork and tried to
understand more of the code.

'Limit' is the total number of packets ESFQ will queue before it starts
finding packets to drop.

ESFQ divides traffic into a number of smaller queues ("slots"), one for
each flow. Flows are distinguished based on whatever aspect of the
packets is hashed, such as source or destination. 'Depth' is the maximum
number of slots.

If there are more flows than 'depth', some flows might actually start
sharing slots. Obviously, this is not good, and fairness will suffer.

If there are 'limit' number of packets, ESFQ will simply drop a packet
from the slot that has the most packets. This doesn't hurt fairness,
since the longest slot will generally correspond to whichever flow has
tried to transfer the most packets recently.

-Corey
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

  parent reply	other threads:[~2007-02-11 19:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-11 12:01 [LARTC] Is ESFQ working? Alejandro Lorenzo Gallego
2007-02-11 12:28 ` Tomasz Chilinski
2007-02-11 13:15 ` Alejandro Lorenzo Gallego
2007-02-11 14:20 ` Tomasz Chilinski
2007-02-11 15:19 ` Alejandro Lorenzo Gallego
2007-02-11 15:48 ` Tomasz Chilinski
2007-02-11 15:59 ` Alejandro Lorenzo Gallego
2007-02-11 19:10 ` Corey Hickey [this message]
2007-02-11 21:49 ` Alejandro Lorenzo Gallego

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=45CF6A2A.3050009@fatooh.org \
    --to=bugfood-ml@fatooh.org \
    --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.