[vdr] Re: VDR 1.3.12 buffer optimizations

[Matthias Schniedermeyer <ms@citd.de>]

On 26.09.2004 17:46, Klaus Schmidinger wrote:

> What I'm aiming at is to make things stable enough to allow at least
> two parallel recordings each on my second (FF) and third (budget) DVB card,
> as well as one recording on my primary FF DVB card plus a Transfer Mode
> originating from any of the three DVB cards. My machine runs at 450 MHz
> and can write to the disk at a continuous rate of 10MB/s, which should
> be more than enough for 5 parallel recordings.

You may get 10MB/s in linear throughput.

But parallel recording is everything else but "linear".

If the filesystem decides not to "interleave" the different recording
you get into "seek"-hell. And performance nears to "nothing".(*)

This is like a non-switched ethernet. Performance drops to a crawl if
you start sending many packets from many stations.




*: In my "day"-job i have this same problems with databases. Sometimes
you have to do things in serial order, or you may wait longer than it
would have taken if you had run the jobs in run serial order because
there is nothing more slowly than a seeking HDD.

(Remember: HDD seek-times are counted in milliseconds that's a very long
time for a computer. This is why you want your RAM for a database to be
larger than your dataset, so that the DBMS can operate from cache. In
most other case performance can/may drop to a crawel. The same problem
you get here, you need enough RAM to compensate the "slow" writespeed of
the HDDs when you have many recordings and "pray" that the kernel is
smart enough to aggregate the writes into larger continious chunks so
that the cache doesn't overflow)



Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.