NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/benchmar/1710

Internet Message Format | 1992-11-17 | 5.6 KB

Xref: sparky comp.benchmarks:1710 comp.arch.storage:781
Path: sparky!uunet!usc!rpi!psinntp!psinntp!parlan!danj
From: [e-mail] (Dan Jones)
Newsgroups: comp.benchmarks,comp.arch.storage
Subject: Re: Disk performance issues, was IDE vs SCSI-2 using iozone
Message-ID: <[e-mail]>
Date: Mon, 16 Nov 92 08:38:53 PST
References: <[e-mail]>
Organization: Parallan Computer, Mountain View CA
Lines: 101


Hope this doesn't confuse too many news readers. I would have followed
up to John's article, but my software thought his article was too long.

>[e-mail] (John Bass) writes:
>>[e-mail] (Randell Jesup) writes:

>The fact is that IDE has become the storage bus of choice for low end
>systems ... and other storage vendors will follow it to reduce interface
>(extra slot/adapter) costs. In laptops, IDE IS THE STORAGE BUS,
>no slots for other choices.

>>    Sounds like the old IPI vs SCSI arguments over whether smart or dumb
>>controllers are better (which is perhaps very similar to our current
>>discussion, with a few caveats).
>>
>>This IS VERY MUCH LIKE that discussion ... BUT about how a seemingly good
>>10 year old decision has gone bad. Given the processor and drive speeds
>of that era ... I also supported SCSI while actively pushing for reduced
>Command Decode times. See article by Dan Jones @ Fortune Systems 1986 I
>think in EDN regarding SCSI performance issues ... resulting from
>the WD1000 emulating SCSI hostadapter I did for them under contract.

>Has IPI largely died due to a lack of volume? ... SCSI proved easier to
>interface, lowering base system costs .... just as IDE has. Certainly
>the standardization on SCSI by Apple after my cheap DDJ published
>hostadapter, was a major volume factor toward the success of SCSI
>and embeded SCSI drives. The market changed so fast after the MacPlus
>that DTC, XEBEC, and OMTI became has been's, even though they shaped
>the entire market up to that point.

Well, very interesting discussion. I was going to sit this one out, but
since John invited me in :-), I had a few comments concerning SCSI and
IPI and by extension IDE. I believe that IDE is the poor man's
IPI. Although some multi-threaded access is possible, as far a seeks are
concerned, locking the controller to a single channel during a read is
very wasteful. Especially, we data is being transferred a media rates.
As such, it is a holdover from the days when intelligence was
too expensive to waste on individual disk drives. IDE is cheap and
simple and, will in most cases, give perfectly acceptable performance in
workstation environments.

A multi-drive system will need the capability of a dedicated, tuned
controller design. Unfortunately, I also believe that the economics of
design is weighted against highly tuned controller designs. Storage
Tech's Iceberg design notwithstanding. (Does this mean I have to turn in
my performance squeezer badge?).

When I was at Pyramid Technology, which wasn't so long ago, the best
performing system per dollar was still based on an IPI disk subsystem.
Even so, the customers and the marketplace was pushing Pyramid to become
a SCSI house.  And, Pyramid will switch, although it will be a grudging
switch. Pyramid knows all about tuning SMD drives and IPI drives in systems
with high I/O rates.  Tandem is another company in the process of making
the switch e.g. the Mosaic disk subsystem.

Of course, this is rarified atmosphere for most people, Pyramid and
Tandem deal in database machines with 20-50 disk drives being the norm.
The first 100 disk drive system Pyramid builds will use SCSI devices.

IPI has lost in the marketplace, because a good IPI design takes 5-10
person-years to get out and it immediately becomes obselete when new
drives with faster transfer rates became available. The figures I've
seen give IPI about a 5% share of all 5.25" disk drives. IPI may have
a life based on some applications for a while; since IPI is still the
sequential thruput leader for another year or two.

Just so you know where I am coming from, SCSI designs never become
obsolete; they stick around because no one wants to port the tape
driver :-)

Another problem with IPI (and IDE) is that you really have to know what
you are doing to get good performance. With SCSI, once you've selected
the right drive, you get very good performance with the default mode
page values. Once you have a drive reading at a 1-to-1 interleave and
stuffing the data into a buffer, you've pretty much a happy camper. Sure
the mode pages are set for best "single drive on a SCSI bus performance",
but...that's ok. That covers 90% of the world.

Another problem with IPI is technology tracking.  Although IPI's most
glaring lack was solved in IPI-2 by the addition of a buffer in the drive,
this will allow IPI drives to support ZBR, it remains to be seen whether
this was in time to save IPI in the marketplace.

John's right, that the biggest performance barrier in SCSI devices is
the capability of the device uProcessor. However, in arrays, my
interest in individual drive performance is rivaled by the importance
of SCSI bus connect times. An area where SCSI devices have been
goddawful since time began.

A new day may be coming though, ushered in by Seagate's 3.5" Barracuda.
I haven't had a chance to play with one, but the SCSI chip is a Seagate
custom design and word is that someone in Seagate has been thinking the
right thoughts. Now, we'll just have to see if they can walk that walk.

Dan Jones

Oh, the article was in Computer Technology Review.  John was a major
source of information for that article. Like CPU design, the emphasis
may change, but the basics remain the same.