[Tfug] A/V drives

[Bexley Hall]

Hi, John,

> http://www.google.com/search?q=av+hard+drive
> http://www.pctechguide.com/31HardDisk_AV_capability.htm
> http://www.google.com/search?q=audio+visual+hard+drive
> http://www.reuters.com/article/pressRelease/idUS80351+09-Jan-2008+BW20080109
> http://www.google.com/search?q=av+site%3Ahitachigst.com
> 
> Audio/Visual Seamless Streaming
> http://209.85.173.132/search?q=cache:11eAOBVt58gJ:www.hitachigst.com/tech/techlib.nsf/techdocs/FEF3B52BFE9A054586256E66005AA389/%24file/WP_AV_25March.pdf+av+site:hitachigst.com&hl=en&ct=clnk&cd=1&gl=us&lr=lang_en

Yes, I am familiar with google et al.  :>

What I was hoping to find was someone with firsthand
experience using AV-ish drives.  Most of the literature
speaks in generalities.  I was interested in comments
more along the lines of:
---------
For RS-170, you need XXX bandwidth.  As such, you
need UDMA-xx just as a bare minimum (in the EIDE world)
or UltraXXX for SCSI implementations.

However, if you are running on a multitasking, non-RT
OS, you'll either have to run single user and/or
renice the application to -100 to lock other processes
out of the loop.  Even so, the scheduler's overhead
beats against the process (at 100Hz) sometimes enough
to disrupt the stream.

If you run a striped (EIDE or SCSI) drive array, you
can mask some of these effects due to the combined
effects of the increased device bandwidth *and* the
additional cache usually present on the controller.

Likewise, if you can increase the size of the disk
cache in the kernel to XXX, you can achieve much
the same results (since this buffer, at the data
rates necessary, spans an interval sufficient to
cover the pause introduced by T-cal on non-A/V
drives).

Of course, if your filesystem is fragmented, this
acts as a double whammy -- increasing access times
for the drive *and* increasing power dissipation
by XX% (thereby making T-cal more necessary).

Likewise, if your filesystem implementation is
unable to take advantage of sequential accesses
to the media, you will similarly be crippled.

etc.

For HD, scale all of the above by YYY%.
---------
I suspect that much of the A/V and non-A/V
attempts at multimedia (on mainstream OS's) take
the same open-loop approach that most "real time"
applications do: throw lots of bandwidth at the
problem, cross your fingers and be prepared to
"do it over" when/if it doesn't quite work out.
I suspect the larger caches present in modern
drives also go a long way towards mitigating
these problems (in much the same way that
"burn proof" CD/DVD writers compensated for the
non-RT capabilities of PC OS's by adding large
onboard buffers!)

These are the kinds of things that you won't
find in the literature -- as they rarely qualify
their comments with:  "On a XXX GHz GibbleBox 8
running Fooware 3.5 under WizzBang 9000 using
a pair of striped 100GB Seacrate UDMA133 disks
capturing raw video at 30FPS you will typically
see X dropped frames per second.  However,
replacing the drives with A/V drives reduces the
number of dropped frames to Y.  This suggests
the processor/processing may be a bottleneck..."

OTOH, find someone who has actually *done* this
(and had to address these problems) and you are
more likely to get that information -- either
volunteered *or* after some pointed questioning.

--don