[mythtv] [mythtv-commits] Ticket #2782: automatic simultaneous jobs scaling

[Daniel Kristjansson]

On Fri, 2006-12-08 at 09:29 +0200, osma ahvenlampi wrote:

> It *can* happen, but *will* it? With 2.6.15+ and CFQ I/O queues, I
> can't see it being very realistic. Does anyone have empiric proof? On
> Linux or some other system?

Simple math, lets say you have 4 ATSC recorders which are
recording, and 3 frontends are watching 3 other streams off
your disk, and your disk read/write speed is 21 MB/s. Since
each stream is about 3 MB/s, adding another frontend process
or starting a commercial flagging or transcode process would
bring us over the edge.

In fact we would have long crossed the edge, you need multiple
disks to support more than 3 ATSC recordings. For recording,
seek time kills you long before actual bandwidth would. We've
added buffering at several levels to allow this much activity,
when I first started using MythTV copying a file would kill
my single HDTV recording.

Even though I run my commercial flag processes at the slowest
setting and they use only a 1-3% of CPU I do sometimes have to
cancel them for playback to work well. So CPU usage is not a
factor for me, disk usage is the factor that matters. For
others network usage would be. Imagine streaming video for
playback to a remote frontend over your wireless network,
how many transcode jobs can you run at the same time over
that 11 or 54 megaBIT non-duplex connection without affecting
the stream that someone is watching? Or even 100-Base-T?

So there are three major factors: CPUs, disks and networks.
There are probably more factors that matter, but I think
these three should be addressed at a minimum before it could
be something that doesn't need tweaking.

-- Daniel

BTW I get fast CPUs, quiet hard drives, and my network is
    1000-Base-T. Other people have different priorities so
    will have different stats.