Date: Sat, 25 Apr 1998 00:24:46 -0600 (MDT) From: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> To: dwilde1@ibm.net Cc: hardware@FreeBSD.ORG Subject: Re: *** Real Action Item: SPECweb Message-ID: <199804250624.AAA04043@narnia.plutotech.com> In-Reply-To: <199804242002.NAA01282@dingo.cdrom.com> <354141D9.B1B9B36D@ibm.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> Say 2 DPT's, okay. Now, as to the disks themselves. Does anybody know if > there's a disk that's intelligent enough to modify it's cacheing > algorithms for small-file transfers as opposed to large file work? It > seems to me that everybody's jumping on this so-called streaming-video > bonanza that's going to be here Real Soon Now, and that's strictly a > read-ahead situation. It is only a read-ahead/write behind issue if you are dealing with a single stream of video that was recorded in a relatively contiguous manner. When you have to record or play back multiple 25mb (DVCPro), 50mb (DVCPro-50), 270mb (Uncompressed 525 SDTV with vertical interval), or even 360mb (16x9 525 Uncompressed or 720P or 1080i HDTV compressed) you are really seek bound. Luckily most multi-stream applications are in the broacast realm where compressed formats are acceptable (DVCPro 25 or 50), but then they want even more streams, meaning more fragmenttation, and more seeks. Of couse it is possible to do all of this, using FreeBSD even: http://www.plutotech.com/ We now return you to your regularly scheduled hardware discussion. 8-) -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804250624.AAA04043>