From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Furniss Date: Wed, 12 Apr 2006 21:35:58 +0000 Subject: Re: [LARTC] ESFQ not so fair? Message-Id: <443D72BE.6030003@dsl.pipex.com> List-Id: References: <443D5449.20706@uznam.net.pl> In-Reply-To: <443D5449.20706@uznam.net.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: lartc@vger.kernel.org Micha=B3 Margula wrote: > Hello! >=20 > I am using since yesterday ESFQ instead of N HTB queues. It mostly=20 > works OK, but when somebody is using one single sesion (for example=20 > downloading file via FTP), it gets weird speed. For example it is 20=20 > kilobytes pres second, then drops down to 9, then 20 again, and then=20 > slowly to 0 and stops. But when using download accelererator of some=20 > kind or bittorrent client which uses many connections, speed seems to be = > stable. >=20 > I am using esfq that way: >=20 > qdisc add dev eth0 parent 1:4 handle 4:0 esfq perturb 600 hash=20 > fwmark divisor 13 > qdisc add dev eth1 parent 1:2 handle 2:0 esfq perturb 600 hash dst=20 > divisor 13 >=20 > On eth0 every IP is marked with different value by IPMARK module. On=20 > eth1 it is not necessary so I use dst hash. I have more values than 2^13 = > so I can't use direct hash. >=20 > Any ideas? Is it possible to use bigger divisor or algorithm is not=20 > designed to deal with bigger hash? Any ideas will be appreciated! >=20 Corey Hickey changed his esfq to use jhash for dst/src/fw - copy of his=20 announce below. Andy. Corey Hickey wrote: > In a recent thread on this list, Robert Kurjata provided me a patch=20 to add > hashing by iptables mark to the Linux 2.4 version of ESFQ. Thanks to that > contribution, I was able to easily add support to the 2.6 port I=20 maintain. > > I found out, however, that the existing hash algorithm results in a=20 lot of > colllisions when the range of hashed values is small. The purturbation > spreads the collisions out a little, but the result still wasn't very > fair, especially when hashing only three fwmark values: 0, 1 and 2. > > So, I wrote an alternative hash function. It's quite simple, and as long > as the range of input values is smaller than the hash table (default=20 1024, > up to 16384), collisions will not happen at all. See the updated README > file for more details. > > Home page: > http://fatooh.org/esfq-2.6/ > > Direct URL: > http://fatooh.org/esfq-2.6/esfq-2.6.13.tar.gz > > README (also available in the tar.gz): > http://fatooh.org/esfq-2.6/current/README > > Try it out, have fun, and if you find a bug or have a suggestion please > send me an email. > > -Corey _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc