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