[mythtv-users] Planning Tuners and Disk I/O for a MythTV Backend System

[Jim Beckett]

Hey all,

Since I started using MythTV a few years ago, I have wondered how you 
would be able to determine how many tuners, and disks, would be optimal 
for a MythTV setup.

I'm going to build a bigger-badder system some day, and I wanted to 
think it through, and get some opinions about it.

Please feel free to set me straight on anything that I have wrong in my 
thought process.
    
I came up with the following (as I understand it):

SATA1 systems can perform a sustained disk write at ~72 MB/second.
SATA2 systems can perform a sustained disk write at ~144 MB/second.

A full transport stream (multiplex, mux) is limited to 38.8 MB/sec data 
rate.
A full transport stream makes up one entire tuning frequency as tuned by 
a physical ATSC tuner.

2 full HD Channels can be carried by a transport stream (19.4 MB/sec 
each) maximum.
1 full HD Channel, and 1 (or more) SD channels can be on a single 
transport stream (total amount of data never exceeding the 38.8 MB/sec 
limit)
Several SD channels can be transmitted on a single transport stream 
(again, total amount of data not exceeding the 38.8 MB/sec limit)

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.

Each physical tuner is assigned a number of virtual tuners so that it 
may capture some, or all, of the data transmitted within a given 
transport stream, but the total is limited to the 38.8 MB/s maximum of 
the transport stream, so virtual tuners don't figure into the equation 
for disk IO.
 
I imagine it would be rare in real world situations to be recording the 
entire contents of multiple data streams, and that my concern is 
probably not an issue for most people, but could it happen?

The data above suggests to me that some configurations could have some 
issues, so I charted it out:


Single Disk Storage

Number of disks:       Tuners    Maximum Concurrent Recording Capablility

Single-Disk (SATA1)    1       Can record 1 transport stream (38.8 MB/s 
Maximum data transfer possible. )

Single-Disk (SATA1)    2        Can record 2 transport streams (77.6 
MB/s Maximum data transfer possible.)
^** This has potential to over-run the disk IO write capability **

Single-Disk (SATA1)    3        Can record 3 transport streams (116.4 
MB/s Maximum data transfer possible.)
^** This has potential to over-run the disk IO write capability **

Single-Disk (SATA1)    4        Can record 4 transport streams (155.2 
MB/s Maximum data transfer possible.)
^** This has potential to over-run the disk IO write capability **


Single-Disk (SATA2)    1        Can record 1 transport stream (38.8 MB/s 
Maximum data transfer possible. )

Single-Disk (SATA2)    2        Can record 2 transport streams (77.6 
MB/s Maximum data transfer possible. )

Single-Disk (SATA2)    3        Can record 3 transport streams (116.4 
MB/s Maximum data transfer possible. )

Single-Disk (SATA2)    4        Can record 4 transport streams (155.2 
MB/s Maximum data transfer possible. )
^** This has potential to over-run the disk IO write capability **


Multiple Disk Storage (Balancing the Recording Activity Based on IO)

Number of disks:        Tuners    Maximum Concurrent Recording Capablility

Double-Disk (SATA1)    1        Can record 1 transport stream (38.8 MB/s 
Maximum data transfer possible. )

Double-Disk (SATA1)    2        Can record 2 transport streams (77.6 
MB/s Maximum data transfer possible.)

Double-Disk (SATA1)    3        Can record 3 transport streams (116.4 
MB/s Maximum data transfer possible.)  

Double-Disk (SATA1)    4        Can record 4 transport streams (155.2 
MB/s Maximum data transfer possible.)
^** This has potential to over-run the disk IO write capability **

Double-Disk (SATA1)    5        Can record 5 transport streams (194 MB/s 
Maximum data transfer possible.)
^** This has potential to over-run the disk IO write capability **

Double-Disk (SATA1)    6        Can record 6 transport streams (232.8 
MB/s Maximum data transfer possible.)
^** This has potential to over-run the disk IO write capability **

Double-Disk (SATA1)    7        Can record 7 transport streams (271.6 
MB/s Maximum data transfer possible.)
^** This has potential to over-run the disk IO write capability **

Double-Disk (SATA1)    8        Can record 8 transport streams (310.4 
MB/s Maximum data transfer possible.)
^** This has potential to over-run the disk IO write capability **


Double-Disk (SATA2)    1        Can record 1 transport stream (38.8 MB/s 
Maximum data transfer possible. )

Double-Disk (SATA2)    2        Can record 2 transport streams (77.6 
MB/s Maximum data transfer possible. )

Double-Disk (SATA2)    3        Can record 3 transport streams (116.4 
MB/s Maximum data transfer possible. )

Double-Disk (SATA2)    4        Can record 4 transport streams (155.2 
MB/s Maximum data transfer possible. )

Double-Disk (SATA2)    5        Can record 5 transport streams (194 MB/s 
Maximum data transfer possible.)

Double-Disk (SATA2)    6        Can record 6 transport streams (232.8 
MB/s Maximum data transfer possible.)

Double-Disk (SATA2)    7        Can record 7 transport streams (271.6 
MB/s Maximum data transfer possible.)
^** This has potential to over-run the disk IO write capability **

Double-Disk (SATA2)    8        Can record 8 transport streams (310.4 
MB/s Maximum data transfer possible.)
^** This has potential to over-run the disk IO write capability **


I am ignoring the ring buffer, because I am not sure it would be 
reliable if the amount of incoming data exceeds the amount of data the 
disk(s) can record for a sustained period of time.
   
I did not take this any further because it seemed pointless to do so, 
but I am serious about the decisions for when I build the next backend...

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?

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 time.

- Jim