Xref: utzoo comp.arch:4232 comp.unix.wizards:7552
Path: utzoo!mnetor!uunet!husc6!mailrus!tut.cis.ohio-state.edu!rutgers!mtunx!whuts!homxb!ho95e!wcs
From: wcs@ho95e.ATT.COM (Bill.Stewart.<ho95c>)
Newsgroups: comp.arch,comp.unix.wizards
Subject: Re: How fast are your disks?
Message-ID: <2100@ho95e.ATT.COM>
Date: 4 Apr 88 04:12:33 GMT
References: <3842@watcgl.waterloo.edu> <1703@van-bc.UUCP>
Reply-To: wcs@ho95e.UUCP (46323-Bill.Stewart.<ho95c>,2G218,x0705,)
Organization: AT&T Bell Labs 46133, Holmdel, NJ
Lines: 18

In article <1703@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes:
:In article <3842@watcgl.waterloo.edu> tbray@watsol.waterloo.edu (Tim Bray) writes:
:>that Unix can do a maximum of 30 disk I/O's a second".  Somebody else remarked
:On most popular, extant Unix systems 20 - 30 ms is a reasonable figure
:for average seek. Average rotational latency is 8.5 ms. Transfer..  1ms
			[Note 3600rpm = 16.6 sec * 50% = 8.3]

Optimal scheduling can of course reduce this a lot; for relatively
large transfers (even with small blocks), you should get a lot of
blocks/seek, and latency will be lower than 50% rotation.
Unfortunately, stdio BUFSIZE is still typically 512-1024 (i.e. 1 block),
so stdio-based input (and probably output) tends to break this up.
Systems with 4K blocks may do a bit better.
-- 
#				Thanks;
# Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
# So we got out our parsers and debuggers and lexical analyzers and various 
# implements of destruction and went off to clean up the tty driver...