[vdr] Re: performance during cutting

[Arno Esser <arno.esser@gmx.de>]

Unfortunately it seems that my previous email gets lost, so I try it again:

Did you check, if your hd transfer mode works correct. I had the same
problem recently. After some time I detected that the drivers for my onboard raid
controller are not so stable. Due to that dma mode became disabled under high
load and that leads to the same situation as you described.

Arno

> Hi,
> 
> On my machine sometimes it takes nearly 30 seconds to read the
> recordings-list while cutting is in progress. Sometimes vdr even gets 
> a timeout and restarts. Also cueing is nearly impossible. 
> 
> I already tried to slow down the thread by inserting 
> usleep()-calls with several times, but I think
> the main problem is the caching strategy of the kernel/filesystem. There
> is no direct means to get informations about the cache-write-back status
> in order choke the cutting thread for better main-thread reactivity
> (e.g. to read the redordings-list). 
> 
> But we can see how long file-I/O operations take in order to guess the 
> I/O-load. So here is my suggestion:
> 
> 1.  There are priority- (i.e. foreground) and background-I/O operations. 
>     Priority-I/O is recording, playback, etc.
>     Backround-I/O is cutting, writing EPG, etc.
> 
> 2.  We bracket every priority-I/O-call with two function calls:
> 	    start_foreground_io()
> 	    read(...) / write(...) / open(...) / close(...)
> 	    end_foreground_io()
> 
> 3.  We precede every background-I/O-call with a function call:
> 	    start_background_io()
> 	    read(...) / write(...) / open(...) / close(...) 
>     (perhaps also a call to end_background_io() for better readability)
> 
> 4.  In start_foreground_io()/end_foreground_io() we measure the time for 
>     every I/O-operation and keep a statistics (e.g. sliding average) for
> it.
> 
> 5.  When this sliding average exceeds a certain time (e.g. 100 ms) the
>     filesystem write back caches may be full and we have to choke the 
>     background-I/O for some time by calling [u]sleep(...) 
>     (remeber its a background-thread!).
> 
> So this system could control the average delay of the foreground thread
> by choking the background I/O-rate.
> 
> - There are some refinements: The sleep-time could be modified softly 
>   e.g. by some kind of PI-regulator.
> 
> - the start_*_io()-functions could get additional informations about the
>   type and amount of I/O (e.g. the number of bytes to be written).
> 
> - In C++ the calls to start_*_io() and stop_*_io() can be done
>   implicitly by the constructor and destructor of a temporary object:
> 
> 	// doing some stuff
> 	
> 	{	// braces just to limit lifetime of tmp_dummy: 
> 	
> 		ForegroundIO tmp_dummy; 
> 		write(...); 
> 	}
> 	
> 	// doing other stuff
> 
>   This will cause ForegroundIO::ForegroundIO() to be called before
>   write() and ForegroundIO::~ForegroundIO() afterwards.
>     
> What do you think about this?
> 
> Greetings,
> 
> Joachim
> 
> -- 
>  --------------------------------------------------
>  Joachim Thees <thees@informatik.uni-kl.de>
>  Univ. of Kaiserslautern, Computer Networks Group
>  --------------------------------------------------
> 
> 
> 

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net



-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net