ESDI controller recommendations

[Charles Hedrick]

>As I agreed in the article which got him excited, the DPT controller sounds
>good for small, slow computers such as this 20MHz, 8MB clone, for those of
>us without the money, time, talent, or source to fix the SV kernel.

The analog of the DPT controller is also useful for larger systems.  I
think most people believe that the best disk performance from a Sun
4/280 (sorry -- the new models are too new for much experience in the
community) is when using a Ciprico Rimfire SMD controller or something
similar.  It has a 512K cache and does various kinds of readahead.
(However it is normally used with write-through cache, so as not to
require a UPS, although that is under the sysadmin's control.)

I think this discussion has been in all-or-nothing terms that don't
make any sense.  My feeling is that modern I/O systems have
optimizations at several levels, and that the best performance comes
from doing appropriate things in both the kernel and the controller.
Someone pointed to Ethernet controllers as an analog, noting the fact
that the TCP/IP community generally recommends against intelligent
controllers.  This failed to note that even "dumb" Ethernet
controllers have a fair amount of intelligence.  All of the processing
within timing constraints in the range of 1 usec to 1 msec is done by
Ethernet controller chips these days.  What you want in the kernel is
the protocol processing.  Protocol processing has timing constraints
in the range of multiple msec to seconds.

Similarly, I think disk performance comes in two types.  What belongs
in the kernel is file system optimization and caching that does not
depend upon real-time knowledge of what the disk is doing.  What
belongs in the controller are things like zero-latency read/write
(picking up a transfer in the middle because that's where the head
happens to be -- which requires a track-level cache) and track-level
lookahead.  Track-level lookahead is time-critical because you want to
abandon the lookahead operation if there are pending requests that
you'd be better off doing.  On a 3600 RPM disk with 67 sectors, a
sector comes by every 250 microsec.  I think that's a bit fast for a
typical Unix kernel to be doing track-level optimization.

There's a grey area in the middle with head-motion optimization.  It
would certainly be practical to do that in the kernel, and in fact
many kernels have done so.  However since many don't, on pragmatic
grounds it makes sense to include the ability to reorder seeks in the
controller.  Presumably those whose kernels do a better job of
head-motion optization will tell the controller not to do so.

There's also a marketing issue: track-level optimizations are largely
OS-independent, assuming they provide a few parameters to adjust.
Ciprico can sell their controllers for anything that uses a VME bus.
The DPT controller can be used on MS/DOS, Unix, etc.  If you were an
expert in low-level disk optimizations, it would probably make more
sense for you to put your time into a controller than into software.
How would you sell your software?  Given the market, probably an
MS-DOS TSR...  Of course the Unix vendors should be have staffs doing
this kind of thing anyway, but experience shows that few Unix
development staffs have either the interest or the necessary
expertise.