Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!agate!dog.ee.lbl.gov!elf.ee.lbl.gov!torek From: torek@elf.ee.lbl.gov (Chris Torek) Newsgroups: comp.arch Subject: Re: Faster controllers easier and cheaper than fast CPUs.... Message-ID: <10951@dog.ee.lbl.gov> Date: 14 Mar 91 22:39:27 GMT References: <28975@cs.yale.edu> <10773@dog.ee.lbl.gov> <3236@crdos1.crd.ge.COM> <1991Mar12.194704.17859@zoo.toronto.edu> <3253@crdos1.crd.ge.COM> <1991Mar12.233713.5034@bellcore.bellcore.com> <1504@TALOS.UUCP> Reply-To: torek@elf.ee.lbl.gov (Chris Torek) Organization: Lawrence Berkeley Laboratory, Berkeley Lines: 22 X-Local-Date: Thu, 14 Mar 91 14:39:27 PST In article <1504@TALOS.UUCP> jerry@TALOS.UUCP (Jerry Gitomer) writes: >Perhaps this is why the mainframers all do their own disk controllers. Probably true. I was quite shocked to hear that many SCSI controllers take several milliseconds, rather than a few tens of nanoseconds, to decode read adnd write commands. Reducing the latency on this *is* important. (I also found it surprising that SCSI controller people took so long to put 64 kbyte caches in. One obvious use is to do small reads by snarfing up the entire track, starting wherever the disk head is now, and sending the requested sectors back as they enter the cache RAM, i.e., with zero extra overhead but the next read for the same track can be answered without waiting for the disk to rotate. This requires either dual ported RAM or trickery: have the incoming bits written both to cache RAM and, if the sector is in range, to the SCSI-side FIFO pipe feeding back to the main CPU. The latter requires at least a sector sized pipe---which *is* available these days. The chip count does go up, but *read speed is important*.) -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov