[comp.periphs] Disk Performance

jt@jvc.UUCP (Joe Tung) (09/20/89)

Is anyone aware of any studies on disk file organization,
and its design and considerations with respect to computer
performance, operating system and applications?  For example,
why are certain organizations more appropriate for DOS and
others more appropriate for UNIX?  Do supercomputers allow
assisting peripheral managers to dynamically reorganize data
before it's inhaled?  Irregardless, what are the considerations
made for balancing disk performance with everything else??
References are welcome.  Please, send responses or questions
to me at (jt@jvc.uucp or uunet!jvc!jt).  Thank You.


			Ijou, yoroshiku onegai shimashu

m1rcd00@fed.frb.gov (Bob Drzyzgula) (02/02/91)

I am thinking about the purchase of a large SPARC server that would be
used by a couple dozen people. One thing I need to consider is what
kinds of disk drives to use. It is important that the disks that are
chosen offer the best possible performance, without going to outragous
cost.

In the past couple of years, drive interface technology has, as we all
know, been changing quite substantially. Among other things, the result
of all this change is some confusion, or at least lack of
understanding, on my part.  I'd like to correct this, if possible.

A recent product line overview from Seagate illustrates my question fairly
well. Look at the following table:

                  Interface  Nom. Cap. (MB)  xfer rate (MBps)    avg seek (ms)

8" Sabre-6 8HP      IPI-2        2105            24.0              12
8" Sabre-7          IPI-2        3220             4.67             12
8" Sabre-7 2HP      IPI-2        3050             9.34             12

5.25" Elite-1       IPI-2        1200             3.0              11.5  
5.25" Elite-1       SCSI-2       1600             5.0              11.5


Now, without taking into consideration the physical size of the drive,
or the cost, it seems that one would build a machine with the Sabre-6
8HPs. But if you do think about cost, you might discover that you can
get maybe four of the Elite-1s for about the same price. If you then
decide that the lower cost of the Elites justifies sacrificing the high
transfer rates, then how does one decide on an interface?  I'd like to
know that the comparison between SCSI-2 and IPI-2 isn't (or is) as that
between apples and oranges. Is there any reason to prefer a 3.0 MB/Sec
IPI over a 5.0 MB/Sec SCSI? Is there any difference between the
performance characteristics of the two interfaces that would make one
decide that one humungus 4.67 MB/Sec IPI drive is better than two
half-humungus 5.0 MB/Sec SCSI drives, even if the cost is a little
higher? What about the 9.34 MB/Sec drive? What is the state of IPI
controllers and SCSI host adaptors to handle these speeds, and how do
they hold up with multiple devices attached? How do characteristics of
the workload affect these arguments?

Does anyone know if there is any chance that we will soon be able to
carve up these enormous drives into more than 8 partitions on under
SunOS?

These and other questions about drive and controller performance haunt
me as I think about how to spend this fairly large chunk of money. Can
anyone point me in the direction of research papers, white papers,
corporate glossies, etc. etc. that would help me to make these decisions?
Does anyone have thoughts of their own that they would like to share
with me?

Please email responses and I will summarize for the net, if there is
interest...

Thanks,
Bob Drzyzgula
Federal Reserve Board
rcd@fed.frb.gov

yuping@auspex.auspex.com (YuPing Cheng) (02/05/91)

In article <934@arccs2.fed.FRB.GOV> rcd@fed.frb.gov (Bob Drzyzgula) writes:
>Is there any reason to prefer a 3.0 MB/Sec
>IPI over a 5.0 MB/Sec SCSI? Is there any difference between the
>performance characteristics of the two interfaces that would make one
>decide that one humungus 4.67 MB/Sec IPI drive is better than two
>half-humungus 5.0 MB/Sec SCSI drives, even if the cost is a little
>higher? What about the 9.34 MB/Sec drive? What is the state of IPI
>controllers and SCSI host adaptors to handle these speeds, and how do
>they hold up with multiple devices attached? How do characteristics of
>the workload affect these arguments?

We have done extensive study on the disk drive performance and published
the following paper:

 "The Myth of Transfer Rate, The Anatomy of an NFS I/O Operation, How and
 Why SCSI is Better than IPI-2 for NFS?" by Bruce Nelson and Yu-Ping Cheng.
 Technical Report #6, Dec. 1990, Auspex Systems Inc.

If you are interested please send mail to me.

	Yu-Ping Cheng, Auspex Systems Inc. ycheng@auspex.com.

m1rcd00@fed.frb.gov (Bob Drzyzgula) (02/06/91)

Thank you to everyone who sent replies to my question. I had
substantive replies from:

uunet!twinsun.com!eggert (Paul Eggert)
uunet!cs.UAlberta.CA!steve (Steve Sutphen)
uunet!xstor!billbr (Bill Brothers)
David Clapp <uunet!dale.cts.com!clapp>

While these were interesting contributions, I fear they raised
as many, or perhaps more, questions than they answered. Here are
some of these:

* Has anyone done a comparative benchmark of systems similarly configured
except for disk?

* What can one expect transfer rates (disk platter to host memory) to
be for SCSI drives in a UNIX (esp. Sun) environment? Bill Brothers
points out that this may well be significantly less than the 5MB/Sec
quoted for many drives.  Seagate Elite drives quote an internal
transfer rates of 24 to 32 Mbits/sec (3-4 MB/sec if these numbers don't
include any overhead. Older drives such as the Wren 5 have rates around
9-15 Mbits/sec). Does this give any clue to the actual transfer rates
obtainable with these devices? What is the comparable number for IPI
drives of various speeds? If two drives are the same internally but
have SCSI and IPI interfaces, and both quote the same internal xfr
rate, and the SCSI drive has an external xfr rate quoted that is
significantly above the internal rate, then can one assume that these
drives will perform equivalently?

* What is the state of SCSI-to-VME Host adapter performance?

* Drive arrays are interesting creatures. The Ciprico 6600 (I think
that's the number) parallel disk array controller can potentially be
used to stripe across four 5.25" drives, keeping a fifth one with
redundant information so's you can rebuild any drive that craps out (if
it does so before the controller dies, I presume) Two questions:  Has
anyone seen a product made out of this thing? That you can buy? It's
been around for over a year now. And what is the implication of this
being a SCSI-2 device, given the limitations of SCSI cited? Can SCSI-2
really crank at 20 MB/Sec? On a UNIX machine?

And, another couple of questions and comments:

* What are the pros and cons of synchronous SCSI-2? Are there any
reasons *not* to use it?

* Believe it or not, disk drive capacities are now getting to a point
that they really are worrying me. Drive manufacturers seem to be
pushing in the directions of speed and capacity, both at the same time.
If you want faster drives, you gotta buy the bigger ones. I don't know
about you, but for me, 3GB gets to be a little unwieldy, especially
when you can only carve it up into seven or eight chunks. And when one
drive takes care of the entire storage requirements of a machine, how
do you take advantage of multiple disk arms? Don't you run the risk of
driving up the real-use average seek time if you have to spread heavily
used filesystems all over a single drive? I know that these drives are
quite a bit faster, but running them in parallel should be faster even
yet.

* Are there any signs of IPI-3 intelligent controllers for Suns on
the horizon?

* Re Paul Eggert's comment on MTBFs: Seagate quotes 150,000 Hrs
for the Elite drives, and 250,000 hours in a Class A computer room.
250,000 Hrs is about 28.5 years. Imagine the drum on your IBM 360/20
breaking now for the first time...

* And a solicitation for further comments on these issues...

Thanks again,

Bob Drzyzgula
Federal Reserve Board
rcd@fed.frb.gov
==================================================================
Herewith are the replies:

Paul Eggert had the following comments:
-----------

My first advice is to *benchmark the drives using your application*.  It's OK
to buy blind for toy applications, but if you're contemplating a big purchase
there's no excuse for buying without trying first.  Manufacturers' spec sheets
tell you performance under ideal conditions, not real conditions.

For the drives you list, don't forget to add the average latency to the average
seek time.  On typical 3600 RPM drives this is 8.33ms; it's simple arithmetic
of figuring out how long half a rotation talks.  I believe the Elite-1s rotate
at 5400 rpm, so their average access time is reduced.

My experience is that the prices on these big SCSI drives have fallen
dramatically quite recently -- if you can get them.  Frankly, for most
applications, I don't see how IPI can be worth the big price differential.
Just buy more SCSI drives and do your application in parallel.

The big question is: how reliable are the drives?  In the past this has been a
dominant factor in my decision making, but I'm wondering now how true it is,
anymore.  Most drive vendors are quoting >=100,000 hours (11 years) MTBF.  This
means it's far more probable for your electronics to fry, (or your drives to
become obsolete!), than for them to fail.  If only we had MTBF figures for
entire subsystems!

If you want speed, you might look into the Maxtor P1-12S: average seek time is
10.5ms, latency 8.33ms, reasonable price.  I haven't used one.

Steve Sutphen added:
-------------

I don't have `THE' answer to your question, but did want to point out one
thing.  SCSI is a two step process getting the data from the disk head to
the controller, while IPI-2 is a one-step as was SMD (this is a
simplification).  What happens in SCSI drives is that the data is read off
the disk and put in a local memory.  This memory is then transferred over
the SCSI bus to the host.  When SCSI transfer rates are quoted they are
the maximum clock rate that data can be transferred from the local memory
(a cache) to the host--it bears no relationship to the sustainable
throughput (i.e. how many MB/sec can one read on large transfers).  This
is not to say that the Elite SCSI system is not cost effective for a lot
of applications, I am sure that they are.  From what I have read they are
a wonderful drive (although they are new and unproven for reliability).
The only real way to find out is to do testing (a hard process, maybe
someone else has done some recent tests).


From Bill Brothers,
     -------------

In response to your questions  about large drives and controller
performance... There is no easy answer.  Perhaps one thing that you
didn't mention is transactions per second.  The number of transactions
a given unit can handle dramatically varies from manufacturer to
manufacturer, and so should be considered. This is directly related to
access time.

The biggest problem I see with your analysis fails to take into
consideration the actual operating characteristics of the host adapter
(for SCSI) or the controller (for IPI-2). Being able to dump data at 5
Mbytes per second off of the drive doesn't mean that your host adapter
or bus can take it at that rate. The other part of this is that 5
Mbytes/s is when you issue requests to the drive in chunks of 64K or
more. Standard UNIX requests of 1,2,4, or 8K will not be able to
achieve that data rate.

IPI-2 is sort-of like super ESDI. It has very little overhead and can
handle high transfer rates. Thus, if your machine can actually deal
with the data rates involved, IPI-2 performs much better. Then there is
the issue of cost...

All in all, it is a complex question that has no simple answer. I would
be interested in what other people have to say about it.

And from David Clapp,
         -----------

One other approach to consider is disk arrays. They've been rumored for
years and seem to be available at last. I've seen (no experience!) 
add-on systems from ciprico and bundled offerings from NCR, for example.

This promises to combine the cheap medium performance drives into arrays
that have redundancy and improved performance.
==================================================================