Date: Tue, 4 Mar 1997 06:17:53 -0500 From: "David S. Miller" <davem@jenolan.rutgers.edu> To: wong@rogerswave.ca Cc: 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: <199703041117.GAA12251@jenolan.caipgeneral> In-Reply-To: <Pine.BSF.3.91.970303210747.301A-100000@wong.rogerswave.ca> (message from Ken Wong on Mon, 3 Mar 1997 21:19:39 -0500 (EST))
next in thread | previous in thread | raw e-mail | index | archive | help
Date: Mon, 3 Mar 1997 21:19:39 -0500 (EST) From: Ken Wong <wong@a17b32.rogerswave.ca> 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 /_____________/ / // /_/ ><
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703041117.GAA12251>