Date: Sat, 1 Mar 1997 19:40:50 -0500 From: "David S. Miller" <davem@jenolan.rutgers.edu> To: dg@root.com Cc: netdev@roxanne.nuclecu.unam.mx, hackers@freebsd.org Subject: Re: ok, final sockhash changes, new diff Message-ID: <199703020040.TAA09403@jenolan.caipgeneral> In-Reply-To: <199703011703.JAA05291@root.com> (message from David Greenman on Sat, 01 Mar 1997 09:03:20 -0800)
next in thread | previous in thread | raw e-mail | index | archive | help
From: David Greenman <dg@root.com>
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 /_____________/ / // /_/ ><
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703020040.TAA09403>