[mythtv-users] MythTV performance in a demanding real-life environment

[Chris Pinkham]

* On Mon Apr 09, 2007 at 09:26:03AM -0700, Yeechang Lee wrote:
> Yes. However, as the slave backend's CPU ran the jobs on the
> recordings stored on the frontend/master backend's RAID 5 array, the
> restraining factor was the network connection, not the CPU. Although,

The network connection is only an issue because of that third flagger
running as fast as possible.  The ~realtime flaggers would only be
pulling down at most 19 Megabit plus nfs overhead.

> as noted, two of the jobs in the example I wrote up were realtime and
> the third was not, all three ran at about 60fps. (I've seen speeds

Well, if the ~realtime ones started when the programs started recording
then they ran at 0 FPS for a little while while they waited for
the logo detection buffer to build, then they ran fast so they could
catch up, then they settled down and ran at ~realtime to keep 30
seconds behind live.

> well into the triple digits with recordings local to the slave
> backend's RAID 6 array.)

Yes, I've seen that even on remote storage since all my storage is
remote to my mythjobqueue server.  Gig-E JobQueue server, Gig-E
file server, Gig-E switch.  Even at 100 Megabit, that is 5x the
necessary transfer rate for the max bitrate of a HD recording.
Even if you said 20% overhead for NFS, you're still at 4x so most
people would be bound by CPU speed unless their fileserver couldn't
handle the throughput (which would be pretty lame not to be able
to handle 100 Megabit unless it's a slug or equivalent or something
like the old Snap Servers I have sitting here collecting dust). :)

--
Chris