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@xxxxxxxxxxxx, http://alchemyx.uznam.net.pl/
"W życiu piękne są tylko chwile" [Ryszard Riedel]
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
