Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[vdr] performance during cutting
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
--------------------------------------------------
Home |
Main Index |
Thread Index