[mythtv-users] Commflagging X 4 = CPU ?

[Raymond Wagner]

On 10/29/2011 14:36, Mark Lord wrote:
> On 11-10-29 01:13 PM, Craig Treleaven wrote:
> ..
>> Is the simple rule of thumb that each commflag job should have its
>> own core?
> That would depend upon how fast the cores are.
> On my 2,6GHz Core2 duo backend, commflag takes only 10-25% CPU on a single core,
> so there's no problem with multiple commflags at once per core.

Real time comflagging may only use that little bit of power, because it 
is governed to the recording rate.  It actually uses much less power 
than playback, due to a special facility in FFmpeg that allows MPEG2 to 
be decoded at a much lower resolution (that capability, and subsequent 
speed boost, may end up lost in future syncs).  Post recording 
commflagging will eat up as much CPU as it can, and with decoding and 
processing in separate threads, I've seen it take most of two cores.

It all comes down to the issue that the jobqueue is not designed to 
handle scaling with multiple types of work loads.  Allowing several 
simultaneous jobs may work for real time commflagging, but would be a 
very poor choice for normal commflagging, high IO tasks like lossless 
transcoding, or CPU intensive tasks like normal transcoding.  Similarly, 
one simultaneous job works well for those loads, but leaves your system 
largely idle and wasted for real time commflagging.  It's a difficult 
problem to solve, and there are a couple tickets on trac documenting 
attempts that introduced more bugs on their own.