From: Thomas Jacob <jacob@internet24.de>
To: netfilter@lists.netfilter.org
Subject: Re: need advice for high traffic network
Date: Sat, 21 Jul 2007 01:14:50 +0200 [thread overview]
Message-ID: <20070720231450.GA20743@internet24.de> (raw)
In-Reply-To: <Pine.LNX.4.63.0707201044550.24729@qynat.qvtvafvgr.pbz>
[-- Attachment #1: Type: text/plain, Size: 1442 bytes --]
> you should run the tests. doing a hash across too many buckets ends up
> costing performance as well.
Yes, I should :=)
> you want the list per bucket to not be too long, but you also don't want to
> spend more effort and ram on empty buckets.
What's the extra effort when you have the ram to spare? A worst
you might slightly reduce the cache hit rate.
> setting conntrack_max equal to the number of buckets doesn't mean that you
> will have one entry in each bucket, it means that you will have a lot of
> empty buckets and other buckets with several items in them.
Right, but it's more likely to have short bucket lists if you have
more hash buckets, given the same number of connections, isn't it?
> >The FAQ says though, that one should use odd hash bucket counts, so you
> >might want to decrease that by one.
>
> it's not unusual for simple (i.e. cheap to use) has algorithims to have
> pathalogical results for specific sizes. ideally you want the bucket count
> to be a prime number, if it's not (for example a even power of 2) you can
> get situations where it only puts things in a very small number of buckets.
As far as I understand is, the Jenkins Hash used internally in netfilter
and other parts of the Linux kernel, isn't just your average
text book hash, but something with quite a lot of thought and analysis
behind it:
=> http://www.burtleburtle.net/bob/hash/doobs.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
next prev parent reply other threads:[~2007-07-20 23:14 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-19 22:17 need advice for high traffic network Konstantin Svist
2007-07-19 22:17 ` David Lang
2007-07-19 22:40 ` Konstantin Svist
2007-07-19 22:59 ` Thomas Jacob
2007-07-19 23:17 ` Konstantin Svist
2007-07-19 23:28 ` Thomas Jacob
2007-07-19 23:35 ` Konstantin Svist
2007-07-19 23:44 ` Thomas Jacob
2007-07-20 0:18 ` Konstantin Svist
2007-07-20 7:48 ` Thomas Jacob
2007-07-20 17:51 ` David Lang
2007-07-20 23:14 ` Thomas Jacob [this message]
2007-07-19 23:47 ` even hash tables sizes, FAQ entry Thomas Jacob
2007-07-20 0:13 ` David Lang
2007-07-20 7:41 ` Thomas Jacob
2007-07-20 17:44 ` David Lang
2007-07-20 17:50 ` Patrick McHardy
2007-07-20 18:08 ` David Lang
2007-07-21 3:44 ` Patrick McHardy
2007-08-06 18:50 ` need advice for high traffic network R. DuFresne
2007-07-19 22:49 ` Thomas Jacob
2007-07-19 22:53 ` Konstantin Svist
2007-07-19 23:16 ` David Lang
2007-07-20 14:16 ` Gregory Carter
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=20070720231450.GA20743@internet24.de \
--to=jacob@internet24.de \
--cc=netfilter@lists.netfilter.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.