Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!bionet!apple!brutus.cs.uiuc.edu!usc!rutgers!aramis.rutgers.edu!geneva.rutgers.edu!hedrick From: hedrick@geneva.rutgers.edu (Charles Hedrick) Newsgroups: comp.unix.i386 Subject: Re: ESDI controller recommendations Message-ID: Date: 5 Sep 89 06:35:14 GMT References: <121@mdi386.UUCP> <1474@wb3ffv.ampr.org> <4843@looking.on.ca> <1989Sep4.024559.13279@ddsw1.MCS.COM> <71@calcite.UUCP> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 55 >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.