Path: utzoo!utgpu!cunews!bnrgate!bwdls58!mlord
From: mlord@bwdls58.bnr.ca (Mark Lord)
Newsgroups: comp.sys.ibm.pc.hardware
Subject: Re: IDE drives: good or evil?
Message-ID: <6300@bwdls58.bnr.ca>
Date: 31 Mar 91 16:38:25 GMT
References: <12070002@hplvec.LVLD.HP.COM> <1991Mar24.173308.3337@jwt.UUCP> <1991Mar25.165950.14531@santra.uucp> <1991Mar28.042102.14723@jwt.UUCP>
Sender: mlord@bwdls58.bnr.ca
Reply-To: mlord@bwdls58.bnr.ca (Mark Lord)
Organization: Bell-Northern Research, Ottawa, Canada
Lines: 26

In article <> john@jwt.UUCP (John Temples) writes:
<In article <> mstr@vipunen.hut.fi (Markus Strand) writes:
<>I use on my harddisks tools which compress the disk so the data is continuos,
<>so IDE-drive's cache is just what I need.
<
<A cache is only useful if you're reading data which is already in the
<cache.  If you're reading continuous data, it's not going to be in the
<cache.

Look-ahead caches are very commonplace these days.  For real-world applications
they can improve disk throughput considerably, even if all that an application
does is continuous reading of new data, with no repeats.

However, a good benchmark that does full track reads with little/no processing
of data could be fast enough to bypass the artificial speed-up gained from 
the look-ahead cache.. in other words, it still oughta be possible to measure
the true data-transfer-rate of the physical drive/controller.  But to do this
requires knowledge of the drive geometry, which is not always available with
IDE drives.
-- 
MLORD@BNR.CA  Ottawa, Ontario *** Personal views only ***
begin 644 NOTSHARE.COM ; Free MS-DOS utility - use instead of SHARE.EXE
MZQ.0@/P/=`J`_!9T!2[_+H``L/_/+HX&+`"T2<TAO@,!OX0`N1(`C,B.P/.DS
<^K@A-<TAB1Z``(P&@@"ZA`"X(27-(?NZE@#-)P#-5
``
end