[mythtv-users] Planning Tuners and Disk I/O for a MythTV Backend System
dennis.cartier at gmail.com
Sat Feb 6 13:34:06 UTC 2010
On Sat, Feb 6, 2010 at 3:04 AM, Raymond Wagner <raymond at wagnerrp.com> wrote:
> On 2/6/2010 02:46, Jim Beckett wrote:
>> SATA1 systems can perform a sustained disk write at ~72 MB/second.
>> SATA2 systems can perform a sustained disk write at ~144 MB/second.
> No. SATA1 and 2 are 150MB/s and 300MB/s, respectively. However that is the
> interface bandwidth. It has no bearing on the physical speed of the disk. A
> modern high density disk will average in excess of 100MB/s.
> A full transport stream (multiplex, mux) is limited to 38.8 MB/sec data
> A full QAM256 multiplex will be ~38mbps, while an ATSC multiplex will be
> ~19mbps. Note the big 'B' and small 'b'. 38mbps means 4.75MB/s.
> That leads me to believe that the practical number of physical tuners for
>> a PVR system can be limited by disk IO throughput, and should be an
>> important consideration when designing, and using the system.
> No. You can probably put a dozen digital tuners in a system before you
> might have to worry about exceeding the throughput of a single modern hard
> Taking all this into consideration, is there a mechanism in MythTV that
>> recognizes when disk IO limits are be likely to exceeded? If so, does it
>> adjust the recording schedule, or perhaps, show a conflict?
> No. You're expected to provide a system capable of the necessary throughput
> for all supplied tuners. As long as you're not using framegrabbers, this
> should not be a problem.
> If not, then I suppose it would be something that might interest one of
>> the developers. (I'm not up to speed in C/C++) My thought is that it could
>> make the scheduler even smarter if there is a way to determine/predict the
>> likely data recording rate, based on the number of recordings scheduled, and
>> how much system IO resources would be likely to be available at any given
> MythTV will estimate the storage space a recording will take, and
> auto-expire shows accordingly. It will also perform load balancing across
> multiple disks if you add them to the storage group as independent drives.
Just to provide a real world example to Raymond's post, my master backend
uses 3 HD Homeruns (6 tuners) and on occasion records 6 OTA HD streams
simultaneously. While the backend is recording, there may be up to 2 streams
being watched (1 on the master backend itself and 1 on a frontend) and 2
streams being commercial flagged on a remote backend (my desktop PC). The
disk I/O is spread across 2 drives on the master.
Amazingly, my master backend is an Atom 330 dual core @1.6Ghz, so not a
speedy system by any definition.
What I have found to be key, is as Raymond says, use a capture method that
only has to record the stream (E.g HD Homerun) and use a file system that
can handle huge files adeptly and can be defragged easily (XFS with 500MB
preallocation and nightly online defrag). Also placing the recordings on
dedicated drives (not the OS drive) and sending the commercial flagging off
to a brawnier system also helped keep things running smooth.
I tried a smaller version of the above originally (4 tuners and 2 drives -
including the OS drive) running EXT4 with the master doing the commercial
flagging but it ended badly.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mythtv-users