[mythtv-users] Storage Groups: Usage Preferences

[Chris Pinkham]

* On Tue Mar 06, 2007 at 07:23:02PM +0100, Janne Grunau wrote:
> > 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.

That's exactly what mythcommflag does when running at Low CPU usage.

Low     = sleep some every frame and run niced
Medium  = just run niced, don't sleep any
High    = no sleeping and not nice at all

Realtime flagging of course ignores the CPU setting and tries to stay
as close to realtime as possible (well, within 30 seconds I think). :)

> 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 
> is idle.

I think that can be addressed separately as several people want to do
with adjusting the max number of Jobs based on CPU or system load.

If a user sets their JobQueue CPU usage to Low, and a lossless transcode
fires off while they are recording something else, it could cause problems
with the recording if mythtranscode doesn't honor the CPU setting.

I can also see adding another "Auto" value to the JobQueue CPU setting
that would let jobs throttle themselves based on current load.

> 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 
> state.

Right, that's why Low = nice & sleep, medium = nice, and high = no sleep and
not nice.

> > 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.

A commercial flagging job running at High will use a whole lot more
resources than a recording or a playback since it will run at a few hundred
frames per second on a decent speed CPU.

> I hope I'll find a method to slow down the lossless transcoder if a 
> recording is using the same filesystem.

I'm open to ideas.  I'm not sure that that should be up to the transcoder
though.  Should the Storage Groups scheduling code try to schedule storage
around other things going on, or shoudl it blindly put recordings on
in-use filesystems hoping the app will throttle itself back?  I think
the SG code should be the one to make the decision since it has the bigger
picture of the whole environment.

Time to head home for the day though, so I'll give this some more thought
while driving. :)

--
Chris