NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/sys/sgi/misc/388

Internet Message Format | 1993-01-26 | 3.6 KB

Path: sparky!uunet!olivea!sgigate!sgi!twilight!zola!anchor!olson
From: [e-mail] (Dave Olson)
Newsgroups: comp.sys.sgi.misc
Subject: Re: Disk striping performance
Message-ID: <[e-mail]>
Date: 26 Jan 93 06:59:41 GMT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail] (Net News)
Organization: Silicon Graphics, Inc.  Mountain View, CA
Lines: 55

In <[e-mail]> [e-mail] (Shawn Young) writes:
| Well, the final configuration we are looking at uses hardware which is (I find)
| covered by a non-disclosure agreement, so I am not really in a position to
| elaborate very much. I was hoping for a generalized technical note or something
| of that order. Benchmark data using a multiprocessor R4000 box with single disk
| and striped partitions, where disk I/O is the application bottleneck, would be
| helpful for now (additional examples weouldn't hurt, either :-) ). I am trying
| to ballpark some performance figures and choose or evaluate metrics for a
| performance study on a proposed configuration. Final numbers will be based on
| the actual hardware, but are not necessary for this part of the task.
|
| We are looking at a multiprocessor box (4 CPUs), with a 1.6GB system disk and
| two striped partitions of 8GB and 6.4GB, respectively, comprised of 1.6 GB
| disks. These "product" partitions will contain highly transient data, consisting
| of very large data files which will be transferrred to another host/media soon
| after they are completed and then removed from the disk, as new data files
| are generated.
|
| These files can get very large, and may in some cases fill a whole partition
| (e.g. all 8GB of the larger), in which case, they may be broken at a convenient
| place and completed on the other large product partition.
|
| Third party disks and controllers are not an issue. Standard SGI-provided
| disks and SCSI (at present, anyway) controllers are expected to be used.
|
| If any further info. is required by the SGI guys, we can take this offline in
| e-mail, or I can fill in the blanks after the target hardware is officially
| announced.

At that level of detail, and for this purpose you should go through an
SGI salesman to get the quotes, and what we are officially willing to
sign up for.  The exact disks and disk controllers (and number of
controllers) you use, the amount of memory installed, and other factors
could affect things significantly.

It also depends on whether you are talking about the current MP
machines, or the ones on which the press announcement went out today
(filesystem performance for a configuration such as you mention should
be quite different on the two classes of systems).

In *general*, with two disks per controller, and 6 or 4 (you can't
stripe 5 disks to make 8 GB, assuming you are talking about 1.6 GB
formatted) disks per lv, you should be able to get about 50-80% of the
total disk bandwidth when doing raw i/o (which is sort of pointless for
most people!).  Filesystem i/o will vary.  In particular, the [34]X0
systems (r3k based) are limited by the MP bus on filesystem i/o to
about 6-8 MB/sec per system with current s/w, because of data copying,
no matter how the disks are set up (this is from memory, so I may be
off a bit).  The newer r4k based MP systems are something I'd rather
not say anything about at this point, because I'm not working on them,
and I don't think anything official has been announced.
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   [e-mail]