[mythtv-users] MythTV backend running on NVIDIA Ka-el, 35W replaced by

[Raymond Wagner]

On 03/09/11 15:13, Gary Dawes wrote:
> I appreciate your comments , but to be fair I would hardly call a
> 1.2Ghz Arm underpowered. The box is perfectly up to running as a web
> and database server, and I have been monitoring sine I move the db
> across to it and it has never broken into a sweat. The system with the
> tuners in is a dual core athlon x64, and never does any other than
> idle. in almost 8 years I have never commflagged a program, and have
> not transcoded anything in at least two years or for that matter done
> anything else intensive since dumping software encoding BTTV cards for
> hardware encoding cards several years ago. The only thing which hits
> the box hard is mythfilldatabase, which runs at about 2am when I am
> asleep.

To be fair, a 1.2GHz single core Cortex-A9 is underpowered.  That ARM is
going to be about as powerful as the 9yr old P3 laptop I'm typing this
up on.  Slightly higher clock rate, slightly shorter pipeline, similar
cache size, similar transistor count... Given the additional 10 years of
developement, the Cortex presumably has a better branch predictor and
prefetch.  On the opposite side, lacking the NEON extensions or any
suitable alternative, the Kirkwood CPUs are absolutely pathetic for
floating point performance.  Even if you wanted to use the commflagger,
it would probably run for days on a single HD recording.

ARM processors are designed for one thing, MIPS/watt.  In that regard,
they're fantastic.  For general backend operations, guide download, and
the scheduler, integer instruction performance is all you really care
about.  General backend operations really don't take any performance at
all.  The guide downloader is very intensive, but as you say, it can be
made to happen in the middle of the night when no one cares.  Scheduler
performance is really the key issue.

The more tuners you have, the more channels you have, the more recording
rules you have, it all adds up to very intensive scheduler runs.  The
scheduler runs when you change guide data.  It runs when you bring up or
take down a slave backend.  It runs when you start or complete a
recording, and any time you change tuners when using livetv.  If your
scheduler is running for an extended duration, it starts interfering
with other stuff.  The backend cannot store new seek-points as it's
recording.  The frontend cannot access existing seek-points for
playback.  The frontend cannot bring up the list of recordings or
videos, causing the UI to lock.  The scheduler will even delay startup
of new recordings.  There are some very serious repercussions to running
your backend on slow hardware.

Now depending on your use case, this may not be a problem.  If you only
have access to a few dozen channels over broadcast TV, and one or two
digital tuners, the scheduler times will stay within reasonable limits. 
You can run an independent jobqueue on a frontend to handle commflagging
and transcoding needs.  In the described situation, it can be done.  If
you have hundreds of channels through a cable or satellite subscription,
along with multiple digital tuners using multirec, you're going to have
a very bad experience.  The reason why were so adamant about people
getting real, decently performing hardware is so that it can be expected
to be used in a wide range of applications.  If we drill down to the
absolute bare minimum, people are going to have problems.