From mboxrd@z Thu Jan  1 00:00:00 1970
From: Corey Hickey <bugfood-ml@fatooh.org>
Date: Thu, 13 Apr 2006 02:46:35 +0000
Subject: Re: [LARTC] ESFQ not so fair?
Message-Id: <443DBB8B.5030706@fatooh.org>
List-Id: <lartc.vger.kernel.org>
References: <443D5449.20706@uznam.net.pl>
In-Reply-To: <443D5449.20706@uznam.net.pl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: lartc@vger.kernel.org

Patrick McHardy wrote:
> Andy Furniss wrote:
>> Corey Hickey changed his esfq to use jhash for dst/src/fw - copy of his
>> announce below.
>>
>> Andy.
>>
>> Corey Hickey wrote:
>>> 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
>> 1024,
>>> up to 16384), collisions will not happen at all. See the updated README
>>> file for more details.
> 
> 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.

That should stabilize after it's been running a while and has seen the 
normal range of IP addresses. Anyway, I agree, it's not very good.

Working on ESFQ some more has been on my long-term TODO list, but what 
with getting distracted by mplayer development I didn't get around to 
it... and now I have 1.2 real jobs and 1.0 girlfriends and don't have 
time for much programming. :)

If any of you want to send patches to this list and they don't look bad 
to other readers of the list I'll happily apply them and make a new 
release. Other than that, I can't help you much for now.

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