Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-lcc!ames!mailrus!um-math!hyc
From: hyc@math.lsa.umich.edu (Howard Chu)
Newsgroups: comp.sys.atari.st
Subject: Re: To seek or not to seek.
Message-ID: <517@stag.math.lsa.umich.edu>
Date: 15 Dec 88 04:46:34 GMT
References: <806@yugas.UUCP> <7078@chinet.chi.il.us> <838@cacilj.UUCP> <12297@cup.portal.com> <171@fishpond.UUCP>
Sender: usenet@math.lsa.umich.edu
Reply-To: hyc@math.lsa.umich.edu (Howard Chu)
Organization: University of Michigan Math Dept., Ann Arbor
Lines: 30
UUCP-Path: {mailrus,umix}!um-math!hyc

In article <171@fishpond.UUCP> fnf@fishpond.UUCP (Fred Fish) writes:
>Yes, under 1.3 it is considerably faster.  I just installed a controller
>and disk combo today that gets over 655,000 bytes/sec on reads of 32 Kb or
>more at a time.
>
>The drive is a 3.5" 80 Mb Quantum.
>
>-Fred

How 'bout that... I just installed a Quantum 80S on my system. Nice little
drive. I was consistently getting around 1 megabyte/sec on reads of large
files. My Miniscribes are now out the door...

(By large files, 100K or larger. Like the gcc files & such. Not bad't'all.
Figure it's about 20-30% faster than a Miniscribe 8051S, on the average.)

At this point, I think trying to find an even faster drive would be a losing
proposition. Probably a 28ms drive is going to be the fastest you'd ever
need. And of course, you're not just looking at seek times, but raw data
transfer rates. I suppose drives with faster seek times are also going to
have faster transfer rates, but ya never know.

My observations were based on single accesses of files on non-fragmented
disks, so seek times really shouldn't have been the major factor. I gotta
believe the faster seeks are gonna cut down my compile times though....
--
  /
 /_ , ,_.                      Howard Chu
/ /(_/(__                University of Michigan
    /           Computing Center          College of LS&A
   '              Unix Project          Information Systems