>>In article <dpn2.65.721007601@po.CWRU.Edu>, dpn2@po.CWRU.Edu (Damien P. Neil) writes:
>{Stuff deleted}
>>To make a long story short "if you get a caching
>> disk controller YOU LOSE THE OPTION of where the memory gets used."
>I dissagree. I have a IDE chaching controller on my new PC (486DX-33). At first I was dubious of the benefits of a hardware chache over the software option, but not now.....
You're no doubt running MeSsy-DOgS. This isn't nearly so clear-cut
under any OS that multitasks.
>The main advantage is that your main CPU is not burdend with the mundane chache control functions and can get on with pushing Windows (or whatever) along.
You're concerned about what your CPU might be burdened with in the way
of caching the drive and you're using an *IDE* controller? The CPU
has to be sitting on top of it anyway, so what's the difference? Get
a decent intelligent controller and try the whole thing again.
>It is particularly noticable to me when I'm compiling, I save then compile my source code, with the IDE chache this is done in parallel, software chaching could not do this.
Doesn't the CPU have to be involved in telling an IDE controller what
to do anyway? Given that, what exactly is happening in parallel? Or
do they put a secondary CPU on an IDE when it's set up to do caching?
If so (and I suspect that it IS so), *that* is where your extra speed
is coming from with a caching IDE drive.
>A further advantage is gained if you use "write-back chaching" (disk writes are chached as well as reads). If you use software chaching and your machine crashes (not so unusual even under Win 3.1) bang goes your new data... This does not happen in hardware chaching.
If the CPU is hosed, you're hosed anyway. Why worry about minor
details like the cache not getting flushed?
[Oh -- please hit the key marked ENTER every 72 characters or so.]
--
"Insisting on perfect safety is for people who don't have the balls to live
in the real world." -- Mary Shafer, NASA Ames Dryden
