[vdr] Re: performance during cutting

[Emil Naepflein <Emil.Naepflein@philosys.de>]

On Tue, 26 Mar 2002 17:13:41 +0100 (MET), Joachim Thees
<thees@informatik.uni-kl.de> wrote:

> On the other hand the high bandwith transfer of the cutting thread
> itself also competes with all other (e.g. foreground) disk accesses. 

Just forget the other traffic. It is only about 500 KB/s for each
running recording or playback. Compared to the cutting thread this is
nothing. And for the recording menu there are a lot of disk accesses
necessary to scan all the directories. This info should all be preserved
in the buffers.

> So there is a lack of fairness (large transfers block small ones).  
> The problem is that you canīt set priorities for access to the ressource
> "bandwith to filesystem", so there are no real-time assurances (only
> unfair best effort approaches) in the access to a file under linux.

Disk accesses should be avoided at all. Even you get highest priority,
for reading all the file info it will be to slow because there may be
several hundred disk accesses necessary. The internal caching that Klaus
wants to implement will certainly help for this case, but probably at
the cost of being inconsistent from time to time, especially when the
files are manipulated by external programs.

IMHO this all are only cures for one of the problems which appear when
cutting is started. What is actually necessary is to limit the disk
bandwidth and cpu usage during cutting by doing it only at a specific
rate (like the update rate for inconsistent mirror disks), and on the
other side prevent that the buffer cache is destroyed when reading and
writing large files.

Emil