Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!mips!winchester!mash
From: mash@mips.COM (John Mashey)
Newsgroups: comp.sys.super
Subject: Re: I/O subsystems
Message-ID: <39320@mips.mips.COM>
Date: 12 Jun 90 03:44:12 GMT
References: <201@csinc.UUCP> <253@garth.UUCP> <202@csinc.UUCP> <292@garth.UUCP> <10280@batcomputer.tn.cornell.edu> <359@garth.UUCP> <6374@amelia.nas.nasa.gov> <424@garth.UUCP> <6583@amelia.nas.nasa.gov> <39284@mips.mips.COM> <6662@amelia.nas.nasa.gov>
Sender: news@mips.COM
Reply-To: mash@mips.COM (John Mashey)
Distribution: na
Organization: Your Organization Goes Here
Lines: 20

In article <6662@amelia.nas.nasa.gov> eugene@wilbur.nas.nasa.gov (Eugene N. Miya) writes:
>In article <39284@mips.mips.COM> mash@mips.COM (John Mashey) writes:
>
>>1) I/O will always be a problem, for all of the usual design reasons,
>
>	"When you can give me disks which rotate significantly
>	faster than 3600 RPM, then we can start talking."
>				--Don Senzig
>
>Time to round up all the "usual" suspects. ;)

Seems like the RPM is only suspect #2.  I'd observe that N cheap disks
running in parallel-transfer designs may have N times the "logical"
rotation speed & N times the data xfer rate.... but don't seek in 1/N
of the time of one....  so I'd say that disk seek is suspect #1.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	 mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash 
DDD:  	408-524-7015, 524-8253 or (main number) 408-720-1700
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086