Path: utzoo!attcan!lsuc!maccs!cs4g6ag From: cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) Newsgroups: comp.sys.ibm.pc Subject: Re: Making a RAMDRIVE -- Oops! I meant... Message-ID: <258B2A09.13152@maccs.dcss.mcmaster.ca> Date: 17 Dec 89 05:54:17 GMT References: <18166@netnews.upenn.edu> <2418@jato.Jpl.Nasa.Gov> Reply-To: cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) Organization: McMaster University, Hamilton, Ontario Lines: 25 In article <2418@jato.Jpl.Nasa.Gov> kaleb@mars.UUCP (Kaleb Keithley) writes: [using SMARTDRV.SYS] $Performance index, as returned by CORETEST went from 6 to 30, before and after $cacheing. Transfer rate went from 800,000 bytes/second to 5Mbytes per second. Transfer rate figures are next to meaningless when you have a disk cache installed, because they work by repeatedly reading a small number of tracks, so with a cache they only actually get read once and then they are read from the cache. Most of the time in the real world, this is a very unrealistic assumption. My hard disk without a cache performs at about 200K/s; with a 384K cache in expanded memory, that jumps by a factor of ten. However, I haven't noticed my compiles getting anywhere near ten times faster (try maybe 40-50% ... just a guess). The only time you even begin to approach that kind of performance boost is if all of the files you're accessing (including any executables if you're jumping back and forth between programs) total less than the size of the cache and you're not writing too much data back to disk. Other than that sort of situation, the numbers generated by CORETEST (or any other similar program, for that matter) can be thrown into the recycling bin. -- Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca = "\nI'm only an undergraduate!!!\n"; **************************************************************************** If it's true that love is only a game//Well, then I can play pretend