Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!cs.mu.OZ.AU!munnari.OZ.AU!news.Hawaii.Edu!news.mrtc.org!news.he.net!uwm.edu!newsfeeds.sol.net!news.maxwell.syr.edu!news1.best.com!nntp1.ba.best.com!not-for-mail
From: dillon@flea.best.net (Matt Dillon)
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: 25 Mar 1997 01:27:07 -0800
Organization: BEST Internet Communications, Inc.
Lines: 36
Message-ID: <5h85pb$8b0@flea.best.net>
References: <331BB7DD.28EC@net5.net> <5gsgsm$c5l@gazette.engr.sgi.com> <5gt4n5$9cc@flea.best.net> <5h1nr1$mpo@gazette.engr.sgi.com>
NNTP-Posting-Host: flea.best.net
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:37869 comp.unix.bsd.bsdi.misc:6482 comp.sys.sgi.misc:29450
:In article <5h1nr1$mpo@gazette.engr.sgi.com>,
:Doug Cook <cook@candiru.engr.sgi.com> wrote:
:>
:>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
Doug, what does this have to do with realtime partitions in XFS? All
you have done here is made an obvious statement. I/O Bandwidth is always
an issue, but insofar as XFS goes only video could reasonably be said
to require a realtime partition. You are not going to get better
performance with (as you say) 'where small edits and/or many
tracks are involved'. This is a function of the way the software
builds and manages its data files, not so much a function of whether
those data files reside on a realtime partition or not. Frankly, I
think the whole 'realtime extension' stuff is mostly crap... they
simply cannot guarentee latency to a fine enough grain for it to be
useful to the few systems that DO really need it. When I think
realtime, I think fine-grained deadline guarentees and deadline
scheduling. Nobody does it right.
-Matt