[mythtv-users] Commflag-related IOBOUND errors
ylee at pobox.com
Wed Jan 18 17:43:37 UTC 2006
Brandon Beattie <brandon+myth at linuxis.us> says:
> Every time a recording, transcode, commercial detection, and so on start
> or finish the recordings table is updated.
The IOBOUND errors I mentioned that are occurring at five-minute
multiples (and one-minute multiples before I changed the "check every
x seconds" setting in the backend from the default) occur independent
of any recording starts or stops. As previously mentioned I have set
commflag jobs to only occur in the early morning, and I never do
> If you use EIT monitoring with a HD tuner than every time this
> finishes it can cause the recording scheduler to be re-run.
Sorry, don't know what EIT monitoring is; I use FireWire with my HD
> Adding RAM will not help at all. This is purely a system and disk IO
This both gladdens my wallet while dimming my hopes for
always-pristine (subject to the vagaries of cable provider
compression) HD recordings regardless of circumstance.
> Also, the PCI bus can be occupied and cause data from the card to be
> lost if the system IO can't be freed up quick enough to handle the
> data. HD tuner cards have a rather small cache on them. If
> anything occupies the system IO longer than 500ms then you risk
> losing data from the HD tuner, and Myth and the scheduler does this
> at times.
Hmm. If it's not a swapping issue, perhaps I should turn the
ringbuffer size on the frontend back up to the maximum? I thought that
only applied to Live TV. Is there a separate ringbuffer setting I am
not aware of in 0.18.1? (Live TV is set to record locally, but I
wonder if maybe it's better to trade network bandwidth for disk IO
bandwidth and set it to go to the same place the recordings go to?)
> The best way to fix this? Keep the drive for the database on a
> different disk than one used for recordings.
Done. I keep the database on a local SATA drive, but the recordings go
to an Infrant 600 2TB over gigabit Ethernet . . .
> Use XFS or JFS.
. . . and which uses ext3, not JFS (as I use pretty much everywhere
else), as its filesystem. (Although the Infrant folks use
straightforward md-compatible RAID on the 600 [and even their
proprietary X-RAID on the X6 is md-readable], I think they've tweaked
with the ext3 filesystem code a bit. When I delete a recording, the
system gives me back control as quickly as when I recorded to my JFS-based
RAID array, but only for a split second; then there is a distinct
'hang' for a few moments as the deletions occur. And yes, this does
cause a few bursts of IOBOUNDs when I am doing HDTV recording at the
> Make sure nothing else IO intensive is running when the schedular
That's easy; the MythTV box doesn't do anything else but MythTV, and
the Infrant is going to be dedicated solely to Myth (at least once
I've moved my remaining non-Myth video collection off it).
> Intel based systems have less of a problem than AMD from what I've
> seen (Intel systems with hyper threading that is).
Check that; the MythTV box is a 3.0GHz Pentium 4.
> Reiser is a good choice though for the filesystem holding the
> database, since it does a better job with sub GB size files. =
Like I said, I am using JFS pretty much everywhere else, and that
includes the MythTV box's local disk.
I wonder if this is a latency issue? Unfortuantely I can't tweak up
the latency on my PCI Express gigabit Ethernet card with setpci; I've
Yeechang Lee <ylee at pobox.com> | +1 650 776 7763 | San Francisco CA US
More information about the mythtv-users