Date: Wed, 12 Mar 1997 17:49:48 -0500 From: "David S. Miller" <davem@jenolan.rutgers.edu> To: mark@quickweb.com Cc: hackers@FreeBSD.ORG Subject: Re: Solaris TPC-C benchmarks (with Oracle) Message-ID: <199703122249.RAA21336@jenolan.caipgeneral> In-Reply-To: <Pine.BSF.3.95q.970312155454.16273A-100000@vinyl.quickweb.com> (message from Mark Mayo on Wed, 12 Mar 1997 16:00:42 -0500 (EST))
next in thread | previous in thread | raw e-mail | index | archive | help
Date: Wed, 12 Mar 1997 16:00:42 -0500 (EST) From: Mark Mayo <mark@quickweb.com> I'm going to start really looking into these damn benchmarks, cause I'm sure FreeBSD would blow Solaris out of the water in just about any benchmark imaginable.. I guess I'm ready to assume the role of promoter - but I need some hard stats. As I've conversed with David Greenwald, you are not going to come close to touching Solaris on such things until: 1) The BSD timer code is fixed, walking the entire TCP socket list 7 times per second, and atleast once per connect/bind is a serious bottle neck. 2) Select() is planed down to it's absolute minimum, the best scheme I've seen is to make the kernel implementation and all the back ends do Svr4 poll(), and implemenet select() (so you can still provide that interface) in terms of poll(). It is the only way to kill this bottleneck that I know of. 3) Something intelligent is done with TIME_WAIT'ers. Anything 4.4 derived falls apart at around 1200 or so time wait connections. 4) Improve the header prediction code, see jacobsons one liner comparisons for how it should be done. 5) All the bulk is pulled out of soreceive() and sosend(). I am seriously considering attaching tcp_sendmsg() into the socket read/write operations when a connection hits TCP_ESTABLISHED to avoid all of the slow conditionalized code. There are more, those are just off the top of my head. Solaris's tcp scales nicely (until a certain extremely high rate of incoming connections gets hit) on SMP as well (because writers are in the hash tables often enough that readers begin going to sleep on the hash rw lock). I think TPC costs like $1200.00, but all of the networking end things it does test can be tuned just as effectively using Webstone. The networking you will find is the first order problem, once you have that planed down, then worry about making sure the vm/vfs code can keep up with the transaction rates the net code can actually deliver and sustain. ---------------------------------------------//// 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?199703122249.RAA21336>