🚀 go-pugleaf

joe@grc.genroco.com (Joe Nordman) writes:

>People should also know that the paper which claims IPI to be the wrong 
>choice was written by a company that makes it's money from SCSI.

	Don't apologise.

	They cheated. The comparison is between a "typical" Auspex
NS5000 with 10 concurrent SCSI-1 channels versus a SPARCserver
with 1-4 IPI controllers. The picture gets clearer when statements
like:
	"The Sun ISP-80 controllers handle a 10Mb/S channel transfer
rate and are optimized (with controller buffering) for sequential
read-ahead. Despite this sequential transfer advantage, section 4.3
discusses empirical testing that confirms that the limited drive
concurrency of this style of IPI subsystem greatly restricts NFS
(random access) throughput."

	I particularly get a chuckle out of the line: "Compared to
SCSI, the IPI interface is an unintelligent interface." Now, they're
talking about *their* SCSI interfaces, which are a slick piece of
work - they aren't talking about the lame SCSI you get with your
workstation. They also declined to publish the results of testing
an IPI subsystem with a write cache. :) And they used one controller.
Benchmarking this against a RAID 0 array.

	So, we got this Auspex server with 2 CPUs, *8* *ETHERNETS*
and a RAID 0 array and - well - yeah it kicks ass. You are surprised?

	The paper is bogus and I'm surprised it got past the program
committee. The title is:
	"How and why SCSI is better than IPI for NFS"
	and then they proceed to argue that it's better because,
well, it's cheaper and nothing does particularly well given NFS'
weird load characteristics.
	and *THEN* they conclude:
	"The result is that SCSI disk arrays easily outperformed a
contemporary, optimized IPI drive subsystem on NFS workloads."
	Hangon.
	The paper title should have read:
	"Disk arrays proven fast"
	Rocket science.

mjr.
-- 
                                                 "guns don't die. people do."