From: danj@hub.parallan.com (Dan Jones)
Newsgroups: comp.benchmarks,comp.arch.storage
Subject: Re: Disk performance issues, was IDE vs SCSI-2 using iozone
Date: Mon, 16 Nov 92 08:38:53 PST
Organization: Parallan Computer, Mountain View CA


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.

>jbass@igor.tamri.com (John Bass) writes:
>>jesup@cbmvax.commodore.com (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.

Newsgroups: comp.benchmarks,comp.arch