Xref: utzoo comp.protocols.nfs:1907 comp.arch:21327 Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!linus!agate!ucbvax!dog.ee.lbl.gov!elf.ee.lbl.gov!torek From: torek@elf.ee.lbl.gov (Chris Torek) Newsgroups: comp.protocols.nfs,comp.arch Subject: Re: Incremental sync()s and using disk idle time Message-ID: <10779@dog.ee.lbl.gov> Date: 9 Mar 91 08:45:36 GMT References: <28975@cs.yale.edu> <1991Mar5.223443.21187@ns.uoregon.edu> <1991Mar6.003008.9131@bellcore.bellcore.com> <1991Mar7.115154.4820@hq.demos.su> <1991Mar8.142031.9098@bellcore.bellcore.com> <10773@dog.ee.lbl.gov> Reply-To: torek@elf.ee.lbl.gov (Chris Torek) Organization: Lawrence Berkeley Laboratory, Berkeley Lines: 30 X-Local-Date: Sat, 9 Mar 91 00:45:36 PST In article <10773@dog.ee.lbl.gov> I wrote: >Sometimes I think we need a Coalition to Stamp Out `Smart' I/O Devices, It seems people know exactly what I mean here... I got several replies to this in the span of a few hours. A quote from one of them: >I think it was Rob Pike who once pointed out there is a real >difference between "smart" and "smart-ass" controllers, and that >in his estimation (one which I agree with completely), most >controllers which claim to be smart, are in fact, in the other group. This nails it down pretty well. So: we should call it the `SO SAD Coalition', where `SO SAD' stands for `Stamp Out Smart-Ass Devices'. Note that there is nothing wrong with (truly) intelligent controllers, provided that they do not sacrifice something important to attain this intelligence. Important things that tend to get sacrificed include both speed and flexibility; and in fact, speed and flexibility can get in each other's way, particularly with programmable devices. (For instance, many SCSI controllers take several milliseconds---not microseconds, *milli*seconds---to react to a command. At 3600 RPM, 3 milliseconds is almost 1/5 of a disk revolution. This is a serious delay. Another example is certain Ethernet chips, where the FIFOs are just a bit too short, and when a collision occurs, they goof up the recovery because they cannot `back up' their DMA, so they simply restart with garbage.) -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov