Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!sri-unix!rutgers!labrea!decwrl!pyramid!prls!mips!earl
From: earl@mips.UUCP (Earl Killian)
Newsgroups: comp.arch
Subject: Re: Disk rotational speed vs. striping vs. parallel heads
Message-ID: <611@gumby.UUCP>
Date: Thu, 20-Aug-87 02:22:25 EDT
Article-I.D.: gumby.611
Posted: Thu Aug 20 02:22:25 1987
Date-Received: Sat, 22-Aug-87 11:30:27 EDT
References: <2432@ames.arpa> <3721@well.UUCP> <2838@phri.UUCP> <155@dolphy.UUCP> <219@casemo.UUCP>
Lines: 46

In article <219@casemo.UUCP>, brian@casemo.UUCP (Brian Cuthie) writes:

> More than likely it has six times the drive electronics.  That is it
> requires five more read/write head amplifiers and such.  In fact I would
> bet good money that such a drive has six seperate read/write data lines
> between the SMD controller (not part of the drive) and the drive.  Thus
> the use of such a beast requires a very expensive disk controller as well.

I knew you needed multiple head amplifiers, but I didn't think head
amplifiers were the big cost item in a disk drive (I am a little naive
on these matters).  Are they really costly?  And six separate
read/write data lines to the controller don't sound like big ticket
items either.  (The extra rams required in the controller for
bandwidth and buffering probably add more to the cost.)  Yes, the
controller is probably expensive, but I suspect that's not inherent,
but rather an artifact of not being the volume product.  With the rate
that cpu performance is increasing, it may soon be that such
drives/controllers become the norm.  Let's hope so.  Can someone tell
us where the $ go in drives and controllers?

> > The problem is that with today's [transfer sizes, parallel head
> > disks] may not make much difference.
> This is very untrue in a multi-drive environment.  Most systems have
> several disk drives under the direction of one disk controller.  This
> allows the overlapping of seeks so that while a drive is seeking...

Yes, but the original comment was in the context of speeding up i/o
for a single application, which I thought to be the motivation behind
striping.  Is this incorrect?  Is striping supposed to speed up
multiprogramming i/o in some way?  The message you replied to even
said the point of striping appears to be to garner some of the
well-known multiprogramming advantages you refer to above for a single
application.

> In all the cases I've seen disk striping was not used to increase mbytes/sec
> throughput at all.  Rather, striping reduces the number of seeks necessary
> to access a given chunk of info.  In effect disk striping gives you a disk
> that looks to have #drives*TRACKS/CYL tracks per cylinder.  This is the
> *real* advantage to striping.

I think we're talking about two different mbyte/s here.  You seem to
be talking about mbyte/s during transfer.  I was talking about
effective data rates, which includes the seek time.  The whole idea to
reducing the number of seeks and thus the average seek time is to make
disk i/o faster, is it not?  I.e. to increase the NET mbyte/s rate
seen by the application.