[geeks] Sun Fire V120 Server -vs- Apple Xserve

[Greg A. Woods]

[ On Saturday, June 22, 2002 at 20:36:56 (+1000), Scott Howard wrote: ]
> Subject: Re: [geeks] Sun Fire V120 Server -vs- Apple Xserve
>
> On Thu, Jun 20, 2002 at 09:20:37PM -0400, Greg A. Woods wrote:
> > On a server CPU doesn't usually matter as much as I/O throughput
> > (including memory throughput).  (unless you're really only using your
> > servers for CPU tasks like graphics rendering or code cracking or gene
> > folding or other scientific modeling, etc.)
> 
> err.. or databases, or dynamic web content, or just about anything else
> which runs on a server.  Yes, I/O is important, but CPU is at least equally
> important in most servers - even if only to drive the IO!

I/O devices are usually orders of magnitude slower than even slow old
CPUs.  Do the math.  On anything much faster than a Pentium-90 there's
so much extra CPU for basic general-purpose computing that it makes
sense to "waste" enormous amounts of cycles just in order to avoid one
I/O operation to even a relatively fast disk device.  As long as you can
avoid moving data around on the memory bus too then you can always
afford to run huge and complex algorithms in order to avoid even one I/O.

Meanwhile you still have zillions of cycles left over for user-land
processes...

And besides, we're talking about a machine with two VERY FAST high-end
processors on it!  It's got more than enough CPU to do high-I/O loads,
multi-processing databases, and still get some rendering done in short
order.

> > on its own channel, amazing PCI/AGP throughput, and on top of all that
> > it's got four ATA/100 controllers, one for each disk, and also
> 
> IDE? On a server?  Haven't we had the tag queueing argument on this list
> already?

You obviously didn't read what I wrote:  It's ATA/100, not IDE, and it's
one channel for each disk.  You don't need tag queuing just to get your
damn disk lists sorted appropriately.  In the SCSI world there's still a
raging debate about whether the strategy routine should sort disk blocks
for a given device or not.  However when you have a separate controller
interface for every spindle then there's no question that the I/O
queueing can be done much more efficiently directly in the OS, which
after all has a damn sight better idea of what operations have priority
than any stupid disk drive could ever manage to cipher.

Perhaps you should go and study the Xserve's hardware design a bit
closer, and then look at some (even cheesy vendor) benchmarks to try to
get some idea of what the box will really be capable of.

Maybe you should go borrow three or four ATA/100 PCI bus controllers and
some decent ATA/100 drives and plug them into a high-end server board
that has at least 2 separate PCI buses (i.e. so you can split the ATA
controllers across buses).  See if you can then build a SCSI machine
that'll even come close with the same number of spindles.  I'll be you
have to go to fiberchannel before you can match it.

Undoutably 10k RPM ATA/100 drives are on the horizon.  That'll make even
extremely huge capacity drives blindingly fast on the Xserve.

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods at acm.org>;  <g.a.woods at ieee.org>;  <woods at robohack.ca>
Planix, Inc. <woods at planix.com>; VE3TCP; Secrets of the Weird <woods at weird.com>