Xref: utzoo comp.protocols.nfs:1946 comp.arch:21418 Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!rpi!zaphod.mps.ohio-state.edu!caen!ox.com!b-tech!zeeff From: zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) Newsgroups: comp.protocols.nfs,comp.arch Subject: Re: Incremental sync()s and using disk idle time Message-ID: Date: 13 Mar 91 15:58:28 GMT References: <10773@dog.ee.lbl.gov> <3236@crdos1.crd.ge.COM> <1991Mar12.194704.17859@zoo.toronto.edu> Organization: UMCC Lines: 19 >The only sensible place to put smarts is in host software, where it can >be changed to match the workload and to keep up with new developments. >"Smart" hardware almost always makes policy decisions, which is a mistake. >The money spent on "smartening" the hardware is usually better spent >on making the main CPU faster so that you can get the same performance >with smart *software*... especially since a faster CPU is good for a I don't know about "usually" - depends on how you define "smart". You can't get much main CPU for the couple of dollars more it costs to have smart(er) serial ports (which can provide significant performance increases). Same with smart keyboards, smart graphics controllers, smart terminals, etc. Smart hardware is usually quite effective for small simple jobs. -- Jon Zeeff (NIC handle JZ) zeeff@b-tech.ann-arbor.mi.us