<br><br><div class="gmail_quote">On Sat, Feb 6, 2010 at 3:04 AM, Raymond Wagner <span dir="ltr"><<a href="mailto:raymond@wagnerrp.com">raymond@wagnerrp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On 2/6/2010 02:46, Jim Beckett wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
SATA1 systems can perform a sustained disk write at ~72 MB/second.<br>
SATA2 systems can perform a sustained disk write at ~144 MB/second.<br>
</blockquote>
<br></div>
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.<br>
<a href="http://www.tomshardware.com/charts/2009-3.5-desktop-hard-drive-charts/h2benchw-3.12-Avg-Write-Throughput,1013.html" target="_blank">http://www.tomshardware.com/charts/2009-3.5-desktop-hard-drive-charts/h2benchw-3.12-Avg-Write-Throughput,1013.html</a><div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
A full transport stream (multiplex, mux) is limited to 38.8 MB/sec data rate.<br>
</blockquote>
<br></div>
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.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
</blockquote>
<br></div>
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 drive.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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?<br>
</blockquote>
<br></div>
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.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
</blockquote>
<br></div>
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.<div>
<div></div><div class="h5"><br>
</div></div></blockquote></div><br>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.<br>
<br>Amazingly, my master backend is an Atom 330 dual core @1.6Ghz, so not a speedy system by any definition.<br><br>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.<br>
<br>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.<br><br>Dennis<br>