'm also using older PC types (PIII) and the cpu load of the cutting thread is seriously hampering the resposiveness of vdr.
Is there a way to lower the priority of the thread for cutting ?
I know there are some patches around (cutter-queue; bandwith), but both seems not to address it on the thread priority.
Wouldn't it being a real solution to make the cutter a background task on nice level ? I've tried to understand how vdr sets the thread priority but I got lost. Can somebody shed some light on the was the thrad priorities are assigned and wether it woul be possible to place a single thread at nice level while vdr still uses normal sheduling.
kind regards Peter
peter.dittmann@freenet.de wrote:
'm also using older PC types (PIII) and the cpu load of the cutting thread is seriously hampering the resposiveness of vdr.
Is there a way to lower the priority of the thread for cutting ?
I know there are some patches around (cutter-queue; bandwith), but both seems not to address it on the thread priority.
Wouldn't it being a real solution to make the cutter a background task on nice level ? I've tried to understand how vdr sets the thread priority but I got lost. Can somebody shed some light on the was the thrad priorities are assigned and wether it woul be possible to place a single thread at nice level while vdr still uses normal sheduling.
If you're using the current developer version, simply put a call to
SetPriority(19);
at the beginning of cCuttingThread::Action(). Let me know if this helps, the I'll add it to the official code.
Klaus
Klaus Schmidinger wrote: ...
If you're using the current developer version, simply put a call to
SetPriority(19);
at the beginning of cCuttingThread::Action(). Let me know if this helps, the I'll add it to the official code.
Hi Klaus, while you are at it: would it be difficult to allow more than one concurrent cutting thread?
Carsten.
Carsten Koch wrote:
Klaus Schmidinger wrote: ...
If you're using the current developer version, simply put a call to
SetPriority(19);
at the beginning of cCuttingThread::Action(). Let me know if this helps, the I'll add it to the official code.
Hi Klaus, while you are at it: would it be difficult to allow more than one concurrent cutting thread?
Carsten.
I won't change anything in that area before version 1.4.
Klaus
Hi,
Hi Klaus, while you are at it: would it be difficult to allow more than one concurrent cutting thread?
Concurrent cutting threads would decrease the cutting performance. A queue for cutting would be more helpful like in this patch: http://www.vdr-wiki.de/wiki/index.php/Cutterqueue-patch
Helmut Auer wrote:
Hi,
Hi Klaus, while you are at it: would it be difficult to allow more than one concurrent cutting thread?
Concurrent cutting threads would decrease the cutting performance. A queue for cutting would be more helpful like in this patch: http://www.vdr-wiki.de/wiki/index.php/Cutterqueue-patch
I agree. From the user's standpoint the important points are: I would like to cut many recordings, I do not want to wait for the current cutting to complete before I can start the next one and I would not like the current cutting to slow down my work on the next one or any other interactive use of VDR. I suppose petri's patches support this very well. Has anyone tried them in the latest VDR?
Carsten.
On Sun, 09 Oct 2005 11:50:18 +0200, Klaus Schmidinger wrote:
If you're using the current developer version, simply put a call to
SetPriority(19);
at the beginning of cCuttingThread::Action(). Let me know if this helps, the I'll add it to the official code.
This is pretty useless on my system because the loss of responsiveness is mostly caused by the disk accesses and not by cpu usage.
I have added a usleep() into the copy loop which is executed every 3th loop. This reduces the cutting bandwidth to about 5 MB/s on my system.
Something that limits the disk bandwidth used by cutting combined with a cutting queue would be ideal.
Emil
On Mon, Oct 10, 2005 at 06:52:12AM +0200, Emil Naepflein wrote:
This is pretty useless on my system because the loss of responsiveness is mostly caused by the disk accesses and not by cpu usage.
Are you sure that DMA disk transfers are enabled? If not, the copying with programmed I/O (PIO) will consume CPU.
Marko
On Mon, 10 Oct 2005 09:54:56 +0300, Marko Mäkelä wrote:
On Mon, Oct 10, 2005 at 06:52:12AM +0200, Emil Naepflein wrote:
This is pretty useless on my system because the loss of responsiveness is mostly caused by the disk accesses and not by cpu usage.
Are you sure that DMA disk transfers are enabled? If not, the copying with programmed I/O (PIO) will consume CPU.
As I wrote, there is no problem with cpu usage. And DMA is enabled as I use a Promise SX6000 controller (SCSI interface). The main problem is that the cutting thread reads and writes the data through the buffer cache and purges useful data from the buffer cache. Any disk access when using the menu then is delayed considerably. This is with a 2.4 kernel. The 2.6 kernel behaves much better in this regard.
Emil
Emil Naepflein wrote:
On Mon, 10 Oct 2005 09:54:56 +0300, Marko Mäkelä wrote:
On Mon, Oct 10, 2005 at 06:52:12AM +0200, Emil Naepflein wrote:
This is pretty useless on my system because the loss of responsiveness is mostly caused by the disk accesses and not by cpu usage.
Are you sure that DMA disk transfers are enabled? If not, the copying with programmed I/O (PIO) will consume CPU.
As I wrote, there is no problem with cpu usage. And DMA is enabled as I use a Promise SX6000 controller (SCSI interface). The main problem is that the cutting thread reads and writes the data through the buffer cache and purges useful data from the buffer cache. Any disk access when using the menu then is delayed considerably. This is with a 2.4 kernel. The 2.6 kernel behaves much better in this regard.
Emil
I'm currently in the process of adopting Ralf Müller's patch to avoid trashing the disk cache. Maybe that will help.
Klaus
Klaus Schmidinger wrote:
Emil Naepflein wrote:
On Mon, 10 Oct 2005 09:54:56 +0300, Marko Mäkelä wrote:
On Mon, Oct 10, 2005 at 06:52:12AM +0200, Emil Naepflein wrote:
This is pretty useless on my system because the loss of responsiveness is mostly caused by the disk accesses and not by cpu usage.
Are you sure that DMA disk transfers are enabled? If not, the copying with programmed I/O (PIO) will consume CPU.
As I wrote, there is no problem with cpu usage. And DMA is enabled as I use a Promise SX6000 controller (SCSI interface). The main problem is that the cutting thread reads and writes the data through the buffer cache and purges useful data from the buffer cache. Any disk access when using the menu then is delayed considerably. This is with a 2.4 kernel. The 2.6 kernel behaves much better in this regard.
I'm currently in the process of adopting Ralf Müller's patch to avoid trashing the disk cache. Maybe that will help.
2.6.13+ also supports ionice. That could help to not starve other processes accessing the disk. AFAIK it's on a per process level though so the cutting thread would need to be turned into to a separate cutting process.
cu Ludwig
Hi! I think one way to archieve a faster cutting is to use hard-links instead of copying a video-file without cutmarks in it.
Matthias Schwarzott
-
Carsten Koch -
Emil Naepflein -
Helmut Auer -
Klaus Schmidinger -
Ludwig Nussel -
Marko Mäkelä -
Matthias Schwarzott -
peter.dittmann＠freenet.de