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.
I agree with the later messages stating that cutting queue is much better choice. Also one reader proposed that usleep could be used to limit bandwidth, and had 5MB/s reduction in cutting speed.
Cutting is IO bound operation with harddisk reads and writes. And reading or writing to disk 'exits' from thread to kernel, so that thread waits for disk write to complete until thread code is scheduled to be run again (unless non-blocking disk IO is used).
So in theory this SetPriority would affect cutting speed a bit, because if there is something more important to do after disk IO is done, it would be done first. But it depends in kernel scheduler, some schedulers increase process priorities when they are at IO wait.
Cutting also trashes caching, I didn't check how VDR does cutting, but earlier (1-2 years ago) I think there was a thread on this list of using special disk IO methods for reading disk without caching (data left behind). Read ahead caching is ok.
And finally I think the "cut in place" -patch would remove the need of cutting queues because cutting is more like file renaming than hard copying. So instead of copying 2GB of data (1h recording) perhaps 100MB data is copied, and rest of 1.9GB data is just 'moved' via file renaming. Very fast.
Best regards, Jori
On Dienstag 11 Oktober 2005 09:45, jori.hamalainen@teliasonera.com 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.
I agree with the later messages stating that cutting queue is much better choice. Also one reader proposed that usleep could be used to limit bandwidth, and had 5MB/s reduction in cutting speed.
I would also suggest a bigger block size when copying data - seek operations on a hard disk a much more limiting then IO speed. Currently the maximum is 500k - this results in a lot of unnecessary separate seek/read seek/write operations.
Regards Ralf
I demand that jori.hamalainen@teliasonera.com may or may not have written...
[snip]
Cutting also trashes caching, I didn't check how VDR does cutting, but earlier (1-2 years ago) I think there was a thread on this list of using special disk IO methods for reading disk without caching (data left behind). Read ahead caching is ok.
That'd probably be posix_fadvise() (<fcntl.h>; __USE_XOPEN2K must be defined).
Usage is posix_fadvise (fd, offset, length, advise) where advise is one of FADV_NORMAL, FADV_RANDOM, FADV_SEQUENTIAL, FADV_WILLNEED, FADV_DONTNEED, FADV_NOREUSE.
And finally I think the "cut in place" -patch would remove the need of cutting queues because cutting is more like file renaming than hard copying. [...]
Not renaming. Hard linking, at least where a file would be copied without cuts and is stored on a filesystem which supports hard links. (Symlinks aren't useful here.)