Caching disk controllers and 386 multiprocessor

[Stuart Lynne]

In article <755 at ctisbv.UUCP> pim at ctisbv.UUCP (Pim Zandbergen) writes:
>In article <10 at aostul.UUCP> steveb at aostul.UUCP (Steve Bogner) writes:
>>I would like to know if anyone out there has had
>>experience (good or bad) with the caching disk controllers made
>>by DPT (Distributed Processing Technologies).
>
>And how about a comparison between caching (ESDI) disk controllers
>and the SCSI disk controller made by Adaptec, supported in
>SCO Xenix 2.3GT (and supposedly in SCO Unix 3.2)?
>
>Which has the best performance/price ratio?

What I would like to see is a comparison of a caching disk controller (say a
DPT with 2MB of RAM) and a normal controller (say a WD1006) *plus* the same
amount of memory allocated to block buffers.

I get the impression from the articles I read that the reviewer simply puts
in the caching controller steps back and marvels at the improved response
:-) 

It seems obvious that adding 2MB of buffers is going to help somewhat. 
But where is the best place to put the memory, on the controller or in the 
kernel?

If it's accessible to the kernel then presumably you save a bit of time not
having to move it from the controller to a block buffer (presumably over a
slow AT bus).

If it's on the controller then perhaps you can save some overhead by having the
controller managing it.

I presume it reduces to a comparison of the efficencies of the two block 
bufferring algorithms and the time to transfer between kernel memory and the
controller memory.

One wild idea would be to implement a controller with dual ported memory and
have it interact with the kernel to implement a shared buffer cache. Unix
just ask's for a block and it auto-magically appears in the appropriate
buffer after some period of time. Maybe someone will do this on a 32bit EISA
card!


-- 
Stuart.Lynne at wimsey.bc.ca uunet!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)