[mythtv-users] HELP! I want my mythtv!

Simon Hobson linux at thehobsons.co.uk
Mon Apr 14 12:32:07 UTC 2014


Hika van den Hoven <hikavdh at gmail.com> wrote:

> Of cause there is an overhead and I wasn't thinking of database
> access. But what is the bandwidth of a modern sata system?

That's your problem, because it isn't an issue and it seems you are looking in the wrong place - I doubt there is any Myth system out there where raw bandwidth is the issue.

> So what are we talking of, with present available speed and bandwidth.
> I guess you live ten years in the past.

No, I live in the present. It is not hard to cause I/O problems if you record enough streams. Each stream requires around one write/second, and each write may well involve updating metadata. So one stream alone may cause "seek-write-seek-write" once a second. Add a second recording and you now have four seeks, add another record stream and it's up to 6 - plus extra for more than just the most basic metadata updates on the filesystem.

Back when I had a system with a single disk and which did other tasks, I hit a real limit at around 2 simultaneous recordings and a playback (I turned off commflagging for most recordings because of this). Not just stutter during playback, but actual dropouts in the recorded streams - on top of the above, there was also the database access/updates at start/end of recordings which could really screw things up (every reschedule would reliably cause playback hiccups).

Now I have the OS and DB on it's own SSD, and two large storage drives. I don't hit these problems, and I can manage "lots" of recordings - I think I've seen 6 on the go (UK Freeview, DVB-T, SD, two physical tuners & multirec), but when really busy like that 9and with commflagging going on) I can get slight hiccups on playback. I suspect that there are some optimisations that could be made in terms of record buffer sizes and sync intervals, but I've never had the inclination to investigate.

I'm sure that if you define the conditions then you can come up with scenarios where striped or mirrored drives will be better - but I'd suggest that statistically by the time you get to the sort of load where it's an issue, it's highly unlikely that you won't have recording streams being spread across multiple drives. The most sensible (but apparently due to user pressure, not the default) setting for Myth is to do such load sharing - and it does work. Two (or more) drives with the "write-seek-write-seek" loads spread across them will outperform the same drives in a mirrored array - whatever record load the array can manage, each drive can also manage on it's own.

Once you have this write-seek-write-seek load going on, then the other optimisation available on a mirrored array are "somewhat less effective" - a single read thread will still have to keep seeking back to it's won data, though things would be improved when two read threads are involved. But once again, by the time you get to this level of load, statistically you are highly unlikely to not have the load spread across multiple drives when using them as single drives.

If you stripe your drives, you'll reduce the combined throughput to something similar to one drive on it's own. You'll also increase the chance of data loss - or at least , increase the effects of a drive failure. So for a Myth system there is no benefit, and significant downsides to striping drives.
Mirrored drives won't give you any significant performance enhancement - but will give you that redundancy. *IF* you want the redundancy then mirror drives, if you don't then you are no worse off, and will generally be better off using the drives as single drives and not putting them into arrays.


But as I say, this is getting somewhat off-topic for this list.



More information about the mythtv-users mailing list