🚀 go-pugleaf

The Renaissance Man (ala...@netcom.com) wrote:
<deletions etc>
NB, Im not contesting many of the arguments here, they
are valid, but Im trying to look at a typical user.

: ] If youve got a 4 Meg machine would you upgrade to
: ] 8 Megs or get a 4 Meg cache controller (c.c)?
My example was (perhaps) for the more typical user, with
the standard 4 megs, having Windows etc.

: 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.
As above, most folks dont have EISA, and disk activity is
important - VLB doesnt have burst mode (PCI does), and most machines
are ISA/VLB - the processor time to disk time is far less important.
For ISA this is very important. did I make a point here!?

Getting back to DOOM - on my 8 Meg machine, with 4 Meg SMARTDRV cache
(only for DOOM), I never see disk activity once it has been on for a
while - the same would be true of a 4 Meg controller. But I can cut
this down to 2 Megs when doing some work. A more typical situation
perhaps.

: 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.
Neither would I, just pointing out flexability.

< Linux stuff deleted, irrelevant to DOOM, but interesting because >
< it should make DOS users realize that something better awaits    >
We can Leave this for a Linux group (comp.os.linux.misc).

< Some points on SMARTDRV memory wastage and the benefits of how  >
< contoller processors release more time for the main one.        >

<my duff analogy deleted - getting better>
: 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?
What happens when this kind of system needs to grow and shrink?

Ok, Ill have to admit that Alaric is winning this on most counts.
But I want the last word (in this group at least :) - The final
blow...

Cached controllers are better because they have a seperate processor
to do the work - not just because they have RAM on them. Ideally,
one would have a co-processor for disk management which can 'chat' 
with the main processor about how much memory it needs (using 
the main system RAM) and release it as required. This sounds like
what Alaric mentioned with Linux - more or less. For the DOS
and Windows user who wants a good price/performance improvement
with DISK and other things - get more RAM and use soft cacheing.
If you run DISK intensive stuff - get a cached controller.

bert
--
Where's your other hand.   | 
Between two pillows.       |     r...@dmu.ac.uk 
Those aren't pillows!      |