[mythtv-users] Recording issues with I/O load

[Blammo]

On Wed, Sep 21, 2011 at 1:51 AM, Stefan Lands <e350notifier at alice.de> wrote:
> <snip>
> Well, when the new system runs for itself, theres no problem at all,
> recordings are pretty well. But as soon as I'm starting streaming an
> archived recording from the RAID to my TV (no matter if I do this via
> NFS, UPnP or Samba) the recordings get bad. There are a lot of artefacts
> and audio glitches in the recording. As soon as I stop streaming this
> 'noise' vanishes immediately. The same happens, when I'm  just copying
> an archived recording to my notebook for example, or when I'm md5summing
> any archived video-file on the RAID. It happens every time when I
> generate any mentionable I/O load to the system.
> It happens not, when I'm copying Files from external USB-HDD to the RAID.
> <snip>

In my experience, Myth seems to grab things from any sort of backend,
via stream/nfs/smb/etc, in relatively tiny chunks, requiring a low
latency stream at regular intervals from the backend. I've searched
for ways to increase the size of the buffer, but have been unable to
find anything that helps.

What you're describing sounds a lot like what I've experienced with IO
Schedulers. I've been using "deadline" for a long long time with
outstanding results. Every generation of hardware I upgrade my
backend, I try setting it back to other IO Schedulers, and I always
have to go back to deadline. Now that I'm up to >8 cores and >16
drives of HWRaid I still find deadline a requirement.

In my case there are two behaviors that are removed with deadline. (1)
TFW messages in the backend log (which means garbled recordings) and
(2) "smoothness" of playback on the frontend.

Redhat has a short doc talking about your options :
http://www.redhat.com/magazine/008jun05/features/schedulers/

I set my in the grub.conf -- add it to the append  -- "elevator=deadline"

Because it's all good info, I'm going to copy/paste from a tuning
guide for DRBD.. very applicable here:

-----------

16.3.3. Enabling the deadline I/O scheduler

When used in conjunction with high-performance, write back enabled
hardware RAID controllers, DRBD latency may benefit greatly from using
the simple deadline I/O scheduler, rather than the CFQ scheduler. The
latter is typically enabled by default in reasonably recent kernel
configurations (post-2.6.18 for most distributions). Modifications to
the I/O scheduler configuration may be performed via the sysfs virtual
file system, mounted at /sys. The scheduler configuration is in
/sys/block/<device>, where <device> is the backing device DRBD uses.

Enabling the deadline scheduler works via the following command:

`echo deadline > /sys/block/<device>/queue/scheduler`

You may then also set the following values, which may provide
additional latency benefits:

Disable front merges:
echo 0 > /sys/block/<device>/queue/iosched/front_merges

Reduce read I/O deadline to 150 milliseconds (the default is 500ms):
echo 150 > /sys/block/<device>/queue/iosched/read_expire

Reduce write I/O deadline to 1500 milliseconds (the default is 3000ms):
 echo 1500 > /sys/block/<device>/queue/iosched/write_expire

If these values effect a significant latency improvement, you may want
to make them permanent so they are automatically set at system
startup. Debian and Ubuntu systems provide this functionality via the
sysfsutils package and the /etc/sysfs.conf configuration file.

You may also make a global I/O scheduler selection by passing the
elevator option via your kernel command line. To do so, edit your boot
loader configuration (normally found in /boot/grub/menu.lst if you are
using the GRUB bootloader) and add elevator=deadline to your list of
kernel boot options.

--------------------

Hope this helps.