[LARTC] ESFQ not so fair?

[Michał Margula]

Corey Hickey napisał(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.
> 
> 
> 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.
> 

I am changing size of HTB queue at 01:00 AM and then back at 06:00 AM. 
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 
larger one (16 bits should be enough). I don't care about memory usage, 
mostly important is performance. I am going to get uplink from another 
company and having another few thousands of HTB qdisc is not wise idea :-).


-- 
Michał Margula, alchemyx at uznam.net.pl, http://alchemyx.uznam.net.pl/
"W życiu piękne są tylko chwile" [Ryszard Riedel]