Re: Is ESFQ working?

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sunday 11 February 2007 20:10:34 Corey Hickey wrote:
> 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'.
>

Yep, these fat fingers >_<

> > 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?
>

I know default is 128, i tried 800 to see if it improved fairness, and it 
did :?

> > ¿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.
>

So i only need as many flows as concurrent expected downloaders

> 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.
>

So limit is nearly a free value in what affects fairness

Attachment: pgpUuLvgEe0ht.pgp
Description: PGP signature

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

[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux