Path: utzoo!mnetor!uunet!husc6!linus!encore!bartlett
From: bartlett@encore.UUCP (John Bartlett)
Newsgroups: comp.arch
Subject: Re: Disk drives -- speed of?
Message-ID: <2947@encore.UUCP>
Date: 21 Apr 88 02:25:38 GMT
References: <2746@sundc.UUCP> <76700012@uiucdcsp>
Reply-To: bartlett@encore.UUCP (John Bartlett)
Organization: Encore Computer Corp, Marlboro, MA
Lines: 43

In article <76700012@uiucdcsp> gillies@uiucdcsp.cs.uiuc.edu writes:
>
>Some of the more sophisticated stepper motors (voice-coil?) in
>Winchester disks can do an average TRACK seek in 16.5 ms (CDC Wren).
>But why make the disk spin faster, if the head cannot get to the TRACK
>quickly?  The average TRACK seek time would have to be 8.3ms before it
>would be the main bottleneck in disk random-access performance.

The issue here is (of course) an applications dependent one.  If you have a 
file system making random accesses to a disk in relatively small hunks (<8Kish)
then the data transfer time does in fact become a relatively small amount of
the total I/O time.  If, however, you are transferring much larger blocks, as
is the case in scientific applications (big ones) and may be the case in swap
space, depending on how your flavor of O.S. works, the data transfer time can
be significant. 

The I/O's in our system look something like this:

8 ms average seek time (under load - good seek ordering queues)
8.33 ms average rotational latency
5 ms data transfer time (15 MHz)
1 ms controller overhead

22.33 ms per i/o or 45 i/o per second max.

The SCSI overhead tends to reduce this as well.  We use as a rule of thumb
about 40 I/Os per second per spindle max, and then derate from there based on
how many spindles are on a SCSI cable.

The above numbers show that radically improving data transfer rates for this
application does not buy much.  We should spend our time on cacheing
algorithms, seek algorithms and the like, and figure out how to do larger
blocks of I/O, better seek queuing, and the like.  However, if data transfers
were much bigger, data transfer would indeed have a very direct effect.


John Bartlett	{ihnp4,necntc,talcott,decvax,allegra,linus}!encore!bartlett
Encore Computer Corp.
257 Ceder Hill Street
Marlboro, Mass.  01752
(617) 460-0500

Opinions are not necessarily those of Encore Computer Corp.