Article View: alt.games.doom
Article #63Re: DOOM - READ - RAMDRIVE.SYS
From: ala... The Renaissance Man
Date: Tue, 11 Jan 1994 23:23
Date: Tue, 11 Jan 1994 23:23
84 lines
5036 bytes
5036 bytes
r...@dmu.ac.uk (robert logan) wrote: ] The Renaissance Man (ala...@netcom.com) wrote: ] : Well, personally *I* kind of *LIKE* my hardware cache. I have an EISA ] : 32-bit caching IDE controller, and (a) it's blindingly fast, (b) I don't ] : have to burn conventional memory on loading software caches, (c) cache ] : conflicts are a thing of the past, and (d) I have one cache that works ] : for both DOS and Linux. ] ] Some points here. Which I'll answer here this time, but if it goes any further we really should move the discussion to a more appropriate group. ] If youve got a 4 Meg machine would you upgrade to ] 8 Megs or get a 4 Meg cache controller (c.c)? In that situation, the obvious choice is to upgrade main memory to 8Mb. 4Mb is really inadeuate for any serious use. However, I'm not in that situation; I have 16Mb of main memory plus my 4Mb caching controller. Your mileage may vary, obviously. ] With 8 Megs you can choose to give 1,2,4,6 Megs for a cache ] as you like - and this cache is fast (RAM to RAM). With a ] 4 Meg c.c you run at EISA speed, and are stuck at that size. With a software cache, you can transfer data from system RAM to system RAM, using the system CPU's time, at system bus speed. With an EISA caching controller, you transfer data from controller RAM to system RAM at EISA burst-mode speed, up to 33Mb/sec, using the comtroller's CPU time. My experience, having tried both, and having tested both with four different speed testing utilities plus real-world usage, is that the caching controller is significantly faster and *LOTS* more reliable. And incidentally, if I only had 8Mb, I'd never burn 6Mb of it on cache. With only 8Mb, RAM is too precious to burn more than 2Mb on cache. ] With Linux, you use the full 8 Megs for the system, it uses ] a sophisticated *dynamic* cache allocation scheme - grows and ] shrinks - as needed. It doesnt know of the 4 Megs on a c.c, ] and therefore wastes memory using its sophisticated *dynamic* ] cache allocation scheme. Much the same is true for Windows. The same is *not* true for Windows at all. Windows doesn't *do* any caching of its own. That's why it insists on loading SmartDrive (even if you're already using another, better, software cache). Meanwhile, Linux's own cache can write to controller cache instead of directly to disk - looking like about a hundred times faster disk, to Linux - even if you *don't* install the controller's Unix drivers. ] DOS may seem faster, but Ill bet a good EISA controller (no ] cache) with a software cache of 4 Megs and another 4 Megs ] of RAM is as "blindingly fast" as a 4 Meg c.c on a 4 Meg machine. Well, if we're going to get picky enough at speed comparisons that we're going to worry about the difference between EISA bus speed and main memory bus speed, let me point out that my caching controller (like most others) is a bus-mastering device with its own processor (in this case, an 80186), and is quite happy to go off and perform disk and cache management tasks in the background while the CPU is busy working on other things. With a software cache, the CPU has to take time out to manage the cache. As stated above, my observation - from real world experience, backed up by testing utilities - is that the caching controller *is* faster. Plus, it's one extra device driver and/or TSR I don't have to load - and cache software can be a real memory hog. The biggest value to me of the caching controller over, say, SmartDrive 4.0 (when running DOS), is that I get back almost 40k of conventional memory, *even loading Smartdrive high*. ] My analogy : A car (machine) with a trailer (controller). ] You could improve performance by putting an engine in the ] trailer - or getting a bigger engine for the car. Which ] would you do? Poor analogy. Here's a better one: You have a library with an attendant at the front desk, who checks books in and out *AND* restocks the shelves. You want to improve service at the library. Do you: (a) Tell the front-desk attendant to work harder, or (b) hire an assistant to re-shelve returned books? -- "I am the NRA." \ "Ultimately, the strongest argument for the people Alaric Tekiahyn \ to retain the right to keep and bear arms, is to ala...@netcom.com \ protect themselves against tyranny in government." The Renaissance Man \ -- Thomas Jefferson (exact wording not guaranteed)
Technical Details
Message-ID:
<alaricCJHnMz.Gs4@netcom.com>Path:
mbox-mo1.pugleaf.net!gmd.de!xlink.net!howland.reston.ans.net!agate!apple.com!amd!amdahl!netcomsv!netcom.com!alaricReferences:
<1994Jan8.003408.5577@dmu.ac.uk> <alaricCJE1pD.8Ey@netcom.com> <1994Jan10.132811.18108@dmu.ac.uk>Show Full Headers
Complete Article Headers
Newsgroups: alt.games.doom Path: mbox-mo1.pugleaf.net!gmd.de!xlink.net!howland.reston.ans.net!agate!apple.com!amd!amdahl!netcomsv!netcom.com!alaric From: ala...@netcom.com (The Renaissance Man) Subject: Re: DOOM - READ - RAMDRIVE.SYS Message-ID: <alaricCJHnMz.Gs4@netcom.com> Organization: Tessier Systems Group References: <1994Jan8.003408.5577@dmu.ac.uk> <alaricCJE1pD.8Ey@netcom.com> <1994Jan10.132811.18108@dmu.ac.uk> Date: Tue, 11 Jan 1994 23:23:22 GMT Lines: 84 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit