Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!uwvax!oddjob!mimsy!aplcen!casemo!brian
From: brian@casemo.UUCP (Brian Cuthie )
Newsgroups: comp.arch
Subject: Re: Disk rotational speed vs. striping vs. parallel heads
Message-ID: <219@casemo.UUCP>
Date: Tue, 18-Aug-87 16:28:49 EDT
Article-I.D.: casemo.219
Posted: Tue Aug 18 16:28:49 1987
Date-Received: Thu, 20-Aug-87 05:49:23 EDT
References: <2432@ames.arpa> <3721@well.UUCP> <2838@phri.UUCP> <155@dolphy.UUCP> <600@gumby.UUCP>
Organization: CASE Communications, Columbia, MD
Lines: 74

In article <600@gumby.UUCP>, earl@mips.UUCP (Earl Killian) writes:
> ... I believe I've seen an ad for a parallel head version of the
> nifty little Fujitsu 8in drives.  Unfortunately, it was a lot more
> expensive than the regular version.  I can't imagine why, other than
> it is a specialty item not produced in high volume.  Instead of
> transfering at 2.4 Mbyte/s, it probably transfers at something like
> 14.4 Mbyte/s (I'm guessing that it has 6 surfaces).  I don't know what
> they did to the SMD interface to make it work at these speeds.
> 

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.

> The problem is that with today's software, this may not make much
> difference.  Suppose you do disk i/o in 8K byte chunks.  At 2.4
> Mbyte/s it takes 3.4ms to transfer your chunk.  The average seek time
> is 20ms, so shrinking the transfer time to .56ms saves you very
> little.  To take advantage of these drives, you need software (either

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, data
may be transfered to a drive that has already completed it's seek.  This
method of disk throughput enhancement is quite common in any but the
smallest, cheapest systems.  The faster a drive can transfer data, the
more drives you can put on one controller with no speed degredation.

> in the os, or in the disk controller) that reads a cylinder at a time.
> Since some disk controllers do read and cache a full track at a time,
> this is not implausible.  Doing caching in the controller also limits
> the need for high bandwidth i/o buses, since only the controller would
> see the 14.4 Mbyte/s; transfers of individual blocks from its cache
> would go at the maximum i/o bus rate, which is probably less than 14.4
> Mbyte/s with today's i/o buses.

This buys you NOTHING.  The real problem is i/o bottleneck.   The faster
data can be transfered for task A, the less time task B has to wait for
his data to be transfered.

> 
> To get back the issue that started this all, it seems to me that there
> are two reasons to do disk striping.  (1) you're already using
> parallel head transfers and you need still more bandwidth for a single
> task.  (2) you need more bandwidth for a single task and parallel head
> drives are too expensive.  (3) you can't use parallel head transfers
> because your i/o bus can't hack the bandwidth.  Striping can increase
> the disk thruput within certain limits without increasing the peak
> bandwidth requirement for randomly scattered (i.e. non-contiguous)
> files.
> 

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.  This technique may be totally implimented
in software (in the driver).  Any form a parallel data transfer requires
duplicate read/write electronics for each drive.  Few systems can afford
such excotic hardware.


Cheers,
-Brian

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brian Cuthie
CASE Communications
Columbia, Md. 21046
(301) 290 - 7443

UUCP:	...seismo!mimsy!aplcen!casemo!brian