From owner-freebsd-hackers  Wed Mar  5 05:27:45 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id FAA17053
          for hackers-outgoing; Wed, 5 Mar 1997 05:27:45 -0800 (PST)
Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA17044
          for <hackers@freebsd.org>; Wed, 5 Mar 1997 05:27:35 -0800 (PST)
Message-Id: <199703051327.FAA17044@freefall.freebsd.org>
Received: by cheops.anu.edu.au
	(1.37.109.16/16.2) id AA049128244; Thu, 6 Mar 1997 00:24:04 +1100
From: Darren Reed <avalon@coombs.anu.edu.au>
Subject: Re: ok, final sockhash changes, new diff
To: mingo@pc5829.hil.siemens.at (Ingo Molnar)
Date: Thu, 6 Mar 1997 00:24:04 +1100 (EDT)
Cc: davem@jenolan.rutgers.edu, wong@rogerswave.ca, alan@cymru.net,
        imb@scgt.oz.au, dg@root.com, netdev@roxanne.nuclecu.unam.mx,
        hackers@freebsd.org
In-Reply-To: <Pine.LNX.3.95.970304160729.1660B-100000@pc5829.hil.siemens.at> from "Ingo Molnar" at Mar 4, 97 04:17:07 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In some mail from Ingo Molnar, sie said:
> 
> 
> On Tue, 4 Mar 1997, David S. Miller wrote:
> 
> >    actually, this paper by Larson talks about the hash table with n
> >    items in each packet. when the packet axceed n items, it double its
> >    table size. [...]
> 
> > For servers with bursty patterns (ie. nearly all heavily loaded
> > machines) this scheme can be extremely inefficient, you get this yo-yo
> > effect in the chain lengths over ~4 second intervals of time at 12,000
> > Web operations per second, but then again once you reach that point
> > TIME_WAIT begins to kill you as well and many commercial UNIX's break
> > rfc1122 just to work around this, and that causes so many problems
> > that I don't want to talk about it.
> 
> people with big servers should simply choose bigger HASH_TABLE_SIZE. As
> the caches most probably get trashed between two packet receives anyways,
> this seems to be a non-issue. [3k more nonswappable memory for size 1024,
> who cares?]
> 
> as a rule of thumb: SIZE := max(256,"wc -l /proc/net/tcp") ? 
> 
> [the hash table should be kept compressed to avoid cache pollution]

Why can't it "autoconfigure" according to the size of your RAM ?

i.e. more RAM => bigger server => more users/network connections

Darren

p.s. of course it should be possible to manually override this "number',
for extreme cases, but why build kernels dumb ?