ESDI controller recommendations

Karl Denninger karl at ddsw1.MCS.COM
Sat Sep 2 12:35:11 AEST 1989


In article <4843 at looking.on.ca> brad at looking.on.ca (Brad Templeton) writes:
>While cylinder or track caching is an eminently sensible idea that I
>have been waiting to see for a long time, what is the point in the
>controller or drive sotring more than that?
>
>Surely it makes more sense for the OS to do all other cache duties.
>Why put the 512K in your drive when you can put it in your system and
>bump your cache there?   Other than the CPU overhead of maintaining the
>cache within the OS, I mean.  I would assume the benefit from having
>the cache maintained by software that knows a bit about what's going
>on would outweigh this.

Well, there are lots of "plus"es, and one bad point.

First, the good:

o	The controller can be intimately familiar with the layout of the
	disk itself.  Since it usually is the device that formatted the
	disk, it can take in to account sector skew, interleave, and other
	factors that are quite beyond the OS's control.  For instance, if
	the controller knows that it takes a sector's worth of time to
	switch heads, it can skew the cylinder format so that when going
	from head 1 to head 2, it doesn't "miss" a rotation.  Drivers
	usually aren't nearly this familiar with disk geometry.

o	The controller can cache "raw" writes and reads, something that the
	Unix system does not do.  This means that swap & page operations can
	be nearly instantaneous in many cases unless you completely fill the 
	cache on the controller.  It can also re-order writes back to the disk 
	itself as it sees fit, making it possible to highly optimize the write 
	order (and thus decrease the physical transfer time).

o	The controller can, if desired, physically mirror two disks, reducing
	the probability of failure.

o	In many cases the data is read back from the cache before it is even
	physically written to the disk!  This is particularly true of page
	and swap areas.  I have seen a quantum leap in performance from this
	effect alone.

o	The on-board processor takes the load of the transfer, ordering, and
	cache search instead of your physical processor.  This gives your
	main processor more time to do work for the users.

o	You can retune for a minimal number of buffers, giving even more RAM
	to the users.  This reduces the page fault rate and thus further
	increases performance.

o	You can have more than 16MB in the system without trouble, and use
	nearly none of your "base" 16MB for disk cache.  Again, a
	potentially big win on loaded systems.


And the bad point:

o	If the power fails and you do not have a UPS, you can get royally
	screwed.  Since the RAM onboard is not NV, quite a bit of data can
	be lost if the power goes off.  Yuck.  So buy a UPS (if you can
	afford the cache controller, you can afford the UPS.  Trust me).



Some people have pointed out potential pitfalls in the setup when the system
crashes or the like, or with databases.  These DO NOT EXIST.  The reason is
simple -- the processor on the DPT board is independant from the main
processor.  IF the system crashes, it crashes -- so what?  The DPT board
will finish writing everything in the cache before it stops!  The same holds
true for a DBMS application.  The only way you can lose is if the power goes
off, and that can be protected against for less than the cache controller
board costs!

In short, if you need the performance, and can afford them AND a UPS, these
cards are wonderful.  I highly recommend them for those people who want
near-mainframe disk performance.  We've checked these out, and they win
hands-down over simply "bumping" the cache size in the OS by an equivalent
amount.  Get a 2MB expansion cache board for Unix if you can afford it -- 
the 512K is very, very nice, but the 2MB version has to be seen to be
believed!

Disclaimer:  We handle the DPT boards, as well as systems and the standard
	     controllers/drives.

--
Karl Denninger (karl at ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Public Access Data Line: [+1 312 566-8911], Voice: [+1 312 566-8910]
Macro Computer Solutions, Inc.		"Quality Solutions at a Fair Price"



More information about the Comp.unix.i386 mailing list