From owner-freebsd-hackers  Tue Mar  4 07:14:59 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id HAA25919
          for hackers-outgoing; Tue, 4 Mar 1997 07:14:59 -0800 (PST)
Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA25903
          for <hackers@freebsd.org>; Tue, 4 Mar 1997 07:14:49 -0800 (PST)
Received: from pc5829.hil.siemens.at (root@[10.1.143.100]) by zwei.siemens.at (8.7.5/8.7.3) with ESMTP id QAA20439; Tue, 4 Mar 1997 16:16:16 +0100 (MET)
Received: from localhost (mingo@localhost) by pc5829.hil.siemens.at (8.6.12/8.6.9) with SMTP id QAA01803; Tue, 4 Mar 1997 16:17:07 +0100
Date: Tue, 4 Mar 1997 16:17:07 +0100 (MET)
From: Ingo Molnar <mingo@pc5829.hil.siemens.at>
To: "David S. Miller" <davem@jenolan.rutgers.edu>
cc: wong@rogerswave.ca, alan@cymru.net, imb@scgt.oz.au, dg@root.com,
        netdev@roxanne.nuclecu.unam.mx, hackers@freebsd.org
Subject: Re: ok, final sockhash changes, new diff
In-Reply-To: <199703041117.GAA12251@jenolan.caipgeneral>
Message-ID: <Pine.LNX.3.95.970304160729.1660B-100000@pc5829.hil.siemens.at>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


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]

-- mingo