🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: alt.games.doom
Article #63

Re: DOOM - READ - RAMDRIVE.SYS

#63
From: ala... The Renaissance Man
Date: Tue, 11 Jan 1994 23:23
84 lines
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!alaric
References: <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