[mythtv-users] pixelation when using nfs for playback

[f-myth-users at media.mit.edu]

    > Date: Sat, 14 May 2011 19:07:50 -0400
    > From: Daniel Kristjansson <danielk at cuymedia.net>

    > On Mon, 2011-04-25 at 21:42 -0400, f-myth-users at media.mit.edu wrote:
    > > > Date: Mon, 25 Apr 2011 21:22:57 -0400
    > >     > From: Steven Adeff <adeffs.mythtv at gmail.com>
    > > 
    > >     > running Ubuntu 10.04.2 LTS, if I have my recording drives mounted by
    > >     > nfs I get pixelation on playback, especially of things currently
    > >     > recording.
    > >     > mythbackend:/media/myth/6/	/media/myth/6	nfs	user,bg,rw,rsize=32768,wsize=32768,tcp,intr,nfsvers=3,actimeo=0,async,nobootwait
    > > 
    > >     > is one of my mount options possibly causing this?
    > > 
    > > I'm suspicious of that actimeo=0; it can cause massive slowdowns in
    > > one of the four cases of which is client vs server vs whether you're
    > > pushing or pulling.  (I can forward details if anyone cares.)
    > > 
    > > Try actimeo=1 instead.  You'll be within 1 second of up-to-date,
    > > without the problems.  No idea if that's actually your problem
    > > here, but worth trying.

    > Can you post the details for the massive slowdown? An actimeo=1 adds
    > one second to the channel change time worst case, 500 ms average case,
    > as opposed to the the defaults which break LiveTV since we will
    > timeout before ever seeing data, and as opposed to actimeo=0 which
    > adds no time to the channel change time. I'm curious as to when
    > actimeo=1 might be preferred.

Sure.  Here's the comment describing it from some automation I wrote,
which couldn't tolerate the default of being up to 60 seconds out of
sync between the two filesystems.  (I write big long comments even
when I'm the only one who will ever see the code, because that way
I'll remember why I did it... :)

This describes two machines running 2.6.12-10 (Ubuntu Breezy Badger)
and using NFS v3, since that release predates Ubuntu's v4 implementation.
I have no idea if it's also true of more-modern implementations.  I can
fairly trivially test this under v3 and 11.04 (Natty), but it would take
more work to see if it's still an issue under v4.  I also didn't take the
time to rigorously confirm the guess below with wireshark or anything like
that; once I discovered how to make the problem go away, I was done.

The directory had a couple thousand files in it, of which many were
symlinks elsewhere; I don't know if the behavior would be so bad if
it had, say, ten files in it.  If my guess was correct, it would be
much, much better with a small directory, so try it with one that's
got a bunch of files in it.

Mount options, as reported by /proc/mounts (100 megabit network):

rw,noatime,rsize=32768,wsize=32768,tcp,soft,nfsvers=3,actimeo=1

### With either noac or actimeo=1, we're pretty much up-to-the-second,
### but you should NOT use noac.  Use actimeo=1 instead.  The reason
### is a -50x- performance hit only in the PUSH direction if noac is
### used.  E.g,. -pulling- things from the remote host to the local
### host will work fine, but -pushing- things will run at about 20
### meg/min.  It doesn't matter which way the bits are flowing, as
### long as both ends have noac, nor whether rsync or cp is being
### used, nor whether rsync is bwlimited---what matters is purely
### whether the command that's moving the bits is pushing them away to
### a remote NFS mount or pulling from a remote mount to the local
### disk.  In the push case, performance goes to hell with noac, but
### in the pull case, it seems unaffected.  Using actimeo=1 instead
### seems to work just fine and doesn't screw up our ability to notice
### updates quickly.  (My guess is that the push case causes a
### complete refresh of the entire destination directory's attributes
### every single time the file gets extended, which happens pretty
### much on every packet or bufferful thereof.  So the vast majority
### of the network traffic turns out to be NFS attribute updates
### instead of actual work.)  Note that fixing this at the NFS
### -client- side fixes this, e.g., if A has noac set for its mount
### of B, then pushing -to- B sucks.  But as soon as A's noac is
### remounted as actimeo=1 (even mid-transfer, via "mount remount -o
### actimeo=1 B:/foo /foo"), the push from A to B immediately takes
### off and continues at its more-normal ~1G/min instead of 20M/min.