[mythtv-users] Storage Groups: Usage Preferences
janne-mythtvusers at grunau.be
Tue Mar 6 18:23:02 UTC 2007
On Tuesday 06 March 2007 16:34:02 Chris Pinkham wrote:
> * On Tue Mar 06, 2007 at 03:16:00PM +0100, Janne Grunau wrote:
> > On Tuesday 06 March 2007 10:29:11 Chris Pinkham wrote:
> > > It's a bit more complicated than that. Myth uses weights to
> > > determine what filesystem/directory to record to. The following
> > > default values are used:
> > >
> > > SGweightPerRecording = 10
> > > SGweightPerPlayback = 5
> > > SGweightPerCommFlag = 5
> > > SGweightPerTranscode = 5
> > We might should think of using higher weight for lossless mpeg2
> > transcodes. They are the most IO demanding job we have.
> > I'll look into it.
> Actually now that I think about it, transcode in general may need
> to be higher than recording because it involves both reading and
And depending on the CPU might also use a higher frame rate.
> So SGweightPerTranscode could be at least 15.
> I don't know if it does it, but the lossless transcoder needs
> to honor the JobQueue CPU setting.
How? The trancodes doesn't use much CPU (except I/O wait). The only way
to slow it down would be a sleep() in the main processing loop.
I'm not sure if slowing the lossless transcode from more than 20MByte/s
to below 20mbit/s is a good idea. At least when the rest of the system
A process with nice value 19 is able to use 100% cpu, mythtranscode with
sleep can't use the full I/O bandwidth regardlessly of the system
> We could change SGweightPerTranscode to 15 by default and then
> multiply SGweightPerCommFlag and SGweightPerTranscode by 0.5 (or
> 0.75) if the JobQueue CPU setting is Low or multiply by 1.5 if
> the JobQueue CPU setting is High, that way we weight things more
> if we know they'll use more CPU (hence higher disk I/O).
I'm not sure if this kind of scaling is useful.
I hope I'll find a method to slow down the lossless transcoder if a
recording is using the same filesystem.
More information about the mythtv-users