[vdr] Re: keys: Very slow response to "recording"

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

On 28 Oct 2001 14:59:00 +0200, Usenet-372112@zocki.toppoint.de (Rainer
Zocholl) wrote:

> >Try it directly in recording.c. 
> 
> ?? 

I mean, you should test this by putting the changed command directly
into recording.c. Doing a test from command line is not the same, at
least not when vdr is doing nothing in this moment.

> Hm, just gave the 256MB strip away...

Get it back asap. ;-)

> 
> I remember that ther were a bug in linux kernel, so it
> performs bad with less than 196MB.
> But thought that this was fixed in 2.4.10 (.8?)

I don't know, I use 2.4.4.
 
> If this happens again, i'll try to see what "top" says.

I had 100 % cpu usage when doing concurrent recording and playback
caused by bdflush. After putting in more memory 3 recordings and one
playback now only uses 20 % cpu time on a 700 MHz Duron.

> A problem could be, that large disks are prepared to
> have (in our case senseless) Millions of directories.
> (My ext2 50GB already has 760000(!) available entries...AFAIR)

That should be a problem because the find runs only through the video
subdirectories. The only reason for the bad performance is IMHO that all
the directory data has to be read from the disk. With about 50
recordings with each 5 files liked with symbolic links it may be
necessary to read about 500-600 disk blocks. This may easily cause an
delay of 10-20 s.

Emil