Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.mel.connect.com.au!munnari.OZ.AU!news.ecn.uoknor.edu!feed1.news.erols.com!howland.erols.net!news.mathworks.com!enews.sgi.com!news.sgi.com!gazette.engr.sgi.com!candiru!cook From: cook@candiru.engr.sgi.com (Doug Cook) Newsgroups: comp.unix.bsd.freebsd.misc,comp.unix.bsd.bsdi.misc,comp.sys.sgi.misc Subject: Re: no such thing as a "general user community" Date: 22 Mar 1997 22:52:17 GMT Organization: Silicon Graphics, Inc. Mountain View, CA Lines: 17 Message-ID: <5h1nr1$mpo@gazette.engr.sgi.com> References: <331BB7DD.28EC@net5.net> <5gpf3b$j99@fido.asd.sgi.com> <5gs1de$k3s@flea.best.net> <5gsgsm$c5l@gazette.engr.sgi.com> <5gt4n5$9cc@flea.best.net> NNTP-Posting-Host: candiru.engr.sgi.com Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:37561 comp.unix.bsd.bsdi.misc:6435 comp.sys.sgi.misc:29370 In article <5gt4n5$9cc@flea.best.net>, dillon@flea.best.net writes: > Only if the software is badly designed. 16 bits at 44KHz is > barely 100KBytes/sec. One disk alone can do 8 MBytes/sec > in linear transfer rate. Even if you have to seek 20 times a second > you will still get 4 MBytes/sec over the entire disk... and > that's ONE disk. If you have, say, four 2G disks dedicated > to your edit stream, we're talking around 120 to 160 FULL-bandwidth > tracks running in parallel without any fancy filesystem support. I didn't say people couldn't solve the problem by throwing more disks at it, just that read latency is indeed the main bottleneck for an audio editing system, particularly where small edits and/or many tracks are involved. In fact, you are agreeing with me by saying that the bandwidth is trivial and that the solution is to throw more disks at it. -Doug