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 Message-ID: <Pine.LNX.3.95.970304160729.1660B-100000@pc5829.hil.siemens.at> In-Reply-To: <199703041117.GAA12251@jenolan.caipgeneral>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.95.970304160729.1660B-100000>