Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!sun-barr!newstop!sun!sally!plocher
From: plocher%sally@Sun.COM (John Plocher)
Newsgroups: comp.unix.i386
Subject: Re: ESDI controller recommendations
Message-ID: <123922@sun.Eng.Sun.COM>
Date: 29 Aug 89 20:22:56 GMT
References: <121@mdi386.UUCP> <1474@wb3ffv.ampr.org> <4843@looking.on.ca> <1076@virtech.UUCP>
Sender: news@sun.Eng.Sun.COM
Reply-To: plocher@sun.UUCP (John Plocher)
Organization: Sun Microsystems, Mountain View
Lines: 39

In article <4843@looking.on.ca>, brad@looking.on.ca (Brad Templeton) writes:
> 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


We have here the timeless tradeoff between software and hardware.  The old
proven method of doing I/O is to use the main processor to shove the bits
all over the place.  e.g., MAC Video, Apple ][ floppy, IBM Serial I/O, IBM
hard disk, Sun Monochrome BW2 video, IBM VGA/EGA/CGA/MDA/Herc graphics...

This works well for a minimal system, but the high performance systems all
have migrated to the "add CPUs/smarts to the I/O system" camp.  Examples
here include Digiboard Com 8/i serial boards, TI/Intel graphics chips,
Adaptec SCSI host adapter, and the above mentioned DPT hard disk controller.

The DPT gives you several things besides the basic caching that an OS would find
hard to do simply:

	Host I/O works in parallel with controller/disk reads and writes
	Sector caching instead of track or cyl caching (finer granularity)
	8 sector automatic read ahead w/o missing a rotation - Data is returned to
		host as soon as avaliable, not after all 8 sectors have been read in
	Read ahead is pre-empted by a cache miss from host
	Ordered write back - Writes are cached and elevator sorted by the controller
	250ms latency between host "write" and start of dirty-sector write back
		All writes "succeed" within 0.5ms, actual write may delay ~250ms
	Burst write back if more than 50% of the cache is dirty
	Geometry spoofing (you tell controller what actual geometry is, and what
		your OS can handle (DOS can not access > 1024 cyls, ...) and the
		controller maps between them transparently.

In general, pushing all this off onto the controller is a win because it simplifies
the OS design and results in less main processor overhead to handle I/O to the
disk.

    -John Plocher

A very happy owner of a DPT PM3011 RLL controller