<br><br><div class="gmail_quote">On Thu, Sep 22, 2011 at 12:17 PM, Simon Hobson <span dir="ltr"><<a href="mailto:linux@thehobsons.co.uk">linux@thehobsons.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
>But who uses 2mbps these days?<br>
<br>
Lots of people ! Over here in the UK, DVB-T<br>
(which we generally call Freeview) varies but<br>
isn't a particularly high bit rate. Some of the<br>
commercial channels can be less than 1GByte/hr or<br>
about 2Mbits/s, while the BBC channels can be<br>
more than 3 times that. That's all for SD though<br>
- I'll need a DVB-T2 tuner to get HD.<br></blockquote><div><br><br>Interesting. I'm US based as you probably figured out with the ATSC comment, so I'm not very familiar with DVB as we needed to make up our own version of digital TV for no reason I have understood yet. :) My recordings are also HD, so the required bandwidth goes up a lot. I generally see about 6GB/hr minimum. <br>
<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
That is useful to know.<br>
How is the size of that buffer determined ? Can<br>
it be controlled by the admin ? Other than taking<br>
memory away from other areas, is there any<br>
penalty for using a larger buffer ?<br>
<br></blockquote><div><br><br>It was hardcoded last time I looked in the source. ThreadedFileWriter.cpp IIRC. I doubled it and solved a lot of problems, but the syncs were still killing performance on the array. They don't seem to cause a problem on single disks or the RAID1 it uses now. Removing the sync calls caused other issues, so I just switched away from storing recordings on the RAID6. If I had found a complete solution, I would have sent a patch in, but the things I did never did fix it entirely. Generally speaking, I agree, larger buffers are probably called for on HD material, but even if you buffer a few gig, at some point the HDD has to catch up, or you lose data. Increasing the buffer didn't seem to cause any issues in my testing, but I hardly have a large Myth system compared to others here. The array in question is also rather busy with lots of other tasks, not an ideal place for recordings to go directly to in any case, for the same reason recordings+database on the same spindle isn't the best idea. <br>
<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
However, it isn't all that long since bus<br>
throughput was an issue - especially on (for<br>
example) a SCSI bus with multiple high<br>
performance drives. Yes, in the past I'm been<br>
down the road of carefully arranging my server<br>
drives equally across all the available busses -<br>
but I think then the PCI-something slot was<br>
probably the streaming throughput bottleneck.<br></blockquote><div><br><br>Ah yes, been a while since I had to mess with anything like that. SATA/SAS has made life easy in a number of ways. :) <br></div></div>