(The jump between 64 and 128 MB might be a bit coarse.)
My standpoint is that if you get into situation when you consider more
than 64MB, it's likely that bottleneck is abnormal
Or the user is an aberrated personality like me who
streams compressed archives on the fly. :))
Keep in mind that ring buffer harmonizes *variations* in input rate. It
can't possibly help if the stream can't be maintained at required rate
in *average*, no matter how large the buffer is. In other words I find
it hard to believe that on-the-fly compression of real-life data affects
required ring buffer size very much. If the system is not capable to
maintain flow at target average velocity, then you should strive for
lowering the recording speed, not increasing the buffer size. But as you
still have to pull a lot of data from disk, you still put quite a
pressure on VM subsystem, so direct I/O can still help, as it liberates
the kernel from scanning the memory to free pages to accomodate "never
ending" input in the block buffer [and you effectively get more CPU time
for compression]. "Never ending" refers to the ratio between RAM (minus
ring buffer size:-) and amount of data to be processed.
Pun aside: with 4x DVD you are of course right. But with
16x DVD a 64 MB buffer gives you just three seconds of
reserve.
Yes, which is why I wrote it's on the edge. But idea is also that
average Joe will get hypnotized by progress indicator and abstain from
pressing the buttons and cause massive page faults while the recording
is in progress anyway, while technically minded users like ourselves
will figure out what's appropiate in any particular situation [anyway
too]. Cheers. A.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
