From owner-freebsd-hackers Tue Mar 4 03:18:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA16539 for hackers-outgoing; Tue, 4 Mar 1997 03:18:28 -0800 (PST) Received: from caipfs.rutgers.edu (root@caipfs.rutgers.edu [128.6.37.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA16534 for ; Tue, 4 Mar 1997 03:18:24 -0800 (PST) Received: from jenolan.caipgeneral (jenolan.rutgers.edu [128.6.111.5]) by caipfs.rutgers.edu (8.8.5/8.8.5) with SMTP id GAA29736; Tue, 4 Mar 1997 06:18:05 -0500 (EST) Received: by jenolan.caipgeneral (SMI-8.6/SMI-SVR4) id GAA12251; Tue, 4 Mar 1997 06:17:53 -0500 Date: Tue, 4 Mar 1997 06:17:53 -0500 Message-Id: <199703041117.GAA12251@jenolan.caipgeneral> From: "David S. Miller" To: wong@rogerswave.ca CC: alan@cymru.net, imb@scgt.oz.au, dg@root.com, netdev@roxanne.nuclecu.unam.mx, hackers@freebsd.org In-reply-to: (message from Ken Wong on Mon, 3 Mar 1997 21:19:39 -0500 (EST)) Subject: Re: ok, final sockhash changes, new diff Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Date: Mon, 3 Mar 1997 21:19:39 -0500 (EST) From: Ken Wong 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. Note that in most app, growth shouldn't happen often. however, if overhead is the problem, you can modify the algo a little to search said item k, if the design item is not in k, then search k/2 (asume that you know that to grow the table is doubling the table size). and if found re-insert it in k... 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. ---------------------------------------------//// Yow! 11.26 MB/s remote host TCP bandwidth & //// 199 usec remote TCP latency over 100Mb/s //// ethernet. Beat that! //// -----------------------------------------////__________ o David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ ><