From: "Michał Margula" <alchemyx@uznam.net.pl>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] ESFQ not so fair?
Date: Thu, 13 Apr 2006 10:58:20 +0000 [thread overview]
Message-ID: <443E2ECC.5080504@uznam.net.pl> (raw)
In-Reply-To: <443D5449.20706@uznam.net.pl>
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@uznam.net.pl, http://alchemyx.uznam.net.pl/
"W ¿yciu piêkne s± tylko chwile" [Ryszard Riedel]
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
prev parent reply other threads:[~2006-04-13 10:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-12 19:26 [LARTC] ESFQ not so fair? Michał Margula
2006-04-12 21:35 ` Andy Furniss
2006-04-12 21:43 ` Michał Margula
2006-04-12 21:52 ` Patrick McHardy
2006-04-12 22:19 ` Andy Furniss
2006-04-12 22:24 ` Andy Furniss
2006-04-13 2:46 ` Corey Hickey
2006-04-13 10:58 ` Michał Margula [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=443E2ECC.5080504@uznam.net.pl \
--to=alchemyx@uznam.net.pl \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.