From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-2?Q?Micha=B3_Margula?= Date: Thu, 13 Apr 2006 10:58:20 +0000 Subject: Re: [LARTC] ESFQ not so fair? Message-Id: <443E2ECC.5080504@uznam.net.pl> 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 Corey Hickey napisa=B3(a): >> Using jhash is a probably a good idea, the "improved" hash is broken >> and will cause reordering in some circumstances: >> >> return (h - q->dyn_min) * (q->hash_divisor - 1) / q->dyn_range; >> >> dyn_min, dyn_max and dyn_range, as their name suggests, are adjusted >> dynamically, so the hash function changes whenever one of these values >> changes, resulting in reordering of packets belonging to a single flow. >=20 >=20 > That should stabilize after it's been running a while and has seen the=20 > normal range of IP addresses. Anyway, I agree, it's not very good. >=20 I am changing size of HTB queue at 01:00 AM and then back at 06:00 AM.=20 So it is quite possible that hash used by esfq will never go stable? If I know range of input values will hardcoding that into esfq help? Or maybe there is something similair to esfq with direct hash but a=20 larger one (16 bits should be enough). I don't care about memory usage,=20 mostly important is performance. I am going to get uplink from another=20 company and having another few thousands of HTB qdisc is not wise idea :-). --=20 Micha=B3 Margula, alchemyx@uznam.net.pl, http://alchemyx.uznam.net.pl/ "W =BFyciu pi=EAkne s=B1 tylko chwile" [Ryszard Riedel] _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc