From owner-freebsd-hackers Sat Mar 1 16:41:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA08937 for hackers-outgoing; Sat, 1 Mar 1997 16:41:57 -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 QAA08929 for ; Sat, 1 Mar 1997 16:41:51 -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 TAA08715; Sat, 1 Mar 1997 19:41:02 -0500 (EST) Received: by jenolan.caipgeneral (SMI-8.6/SMI-SVR4) id TAA09403; Sat, 1 Mar 1997 19:40:50 -0500 Date: Sat, 1 Mar 1997 19:40:50 -0500 Message-Id: <199703020040.TAA09403@jenolan.caipgeneral> From: "David S. Miller" To: dg@root.com CC: netdev@roxanne.nuclecu.unam.mx, hackers@freebsd.org In-reply-to: <199703011703.JAA05291@root.com> (message from David Greenman on Sat, 01 Mar 1997 09:03:20 -0800) Subject: Re: ok, final sockhash changes, new diff Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk From: David Greenman Reply-To: dg@root.com Hi, David. I just looked at the hash algorithm you're using in tcp_hashfn()...I think it looks pretty good, and it's easy to see why it would have good distribution properties. I didn't think about using xor when I wrote the stuff for FreeBSD. :-( ...Anyway, I hope you don't mind if I change the algorithm in FreeBSD to use xor's. :-) It seems like the laddr/faddr would likely have a not-very-unique low order portion (since most hosts are assigned addresses in the low range of class A/B/C's), so it seems like this could perhaps be improved by combining the upper word of the IP address with the lower word...but perhaps this would be just extra overhead (since your analysis seems to show the distribution is already quite good). Keep in mind that if you don't consider the local address in the hash you'll get screwed on machines with thousands of IP aliases doing virtual web service for many blocks of class C's. BTW, one thing I didn't see in your code that was suggested to me a few months ago (and is also on my whiteboard), is another queue to move connections that have closed and are just waiting for the 2MSL wait to expire. In the case of busy WWW servers, it's common for the majority of the connections to be in this state, so by moving them off of the regular hashed queue and on to a private hashed queue, you can speed up the lookups for the active connections. Yes, I know about this issue. I didn't want to do it right now. It is an obvious problem, but there are cases where it would actually hurt to go through this effort. In reality my test data shows me: ? egrep TIME_WAIT best.com.1 | wc -l 238 ? egrep TIME_WAIT best.com.2 | wc -l 166 ? egrep TIME_WAIT best.com.3 | wc -l 321 ? egrep TIME_WAIT zero.genx.net.1 | wc -l 39 ? egrep FIN_WAIT zero.genx.net.1 | wc -l 614 ? A lot of machines get killed with stunk FIN_WAIT sockets as well as connections in 2MSL. As shown for zero, the TIME_WAIT connections aren't even worthwhile to deal with as the FIN_WAIT's are eating up most of the connection space. ---------------------------------------------//// 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 /_____________/ / // /_/ ><