[mythtv-users] Tips for user jobs on NFS mounts over Wi-Fi?

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

Step 0:  Do you have anything else on wifi that actually demands
real-time response?  E.g., streaming AV?  If so, move it off wireless
or pick a different band on a different pair of transceivers.

Step 1:  For your particular transcoding job, run a few samples and
time them.  See how long they take.  (For my Handbrake jobs and
parameters, I've found that NTSC SD nature shows with lots of detail
and foliage on some particular CPU might transcode at something
horrible, like 1x or 2x real time, whereas most shows will transcode 
around 4x, and talking-heads might do 7x or more.)

Step 2:  Take those timings, add the input & output sizes, and divide.
That gives you your average bitrate.  See if it comes anywhere near
your measured performance.  That will give you a ballpark estimate
of whether you're at 1%, 10%, 100% or 1000% of what your wireless
can do.  (You can measure raw performance by just doing something
like "time cat < /nfs/mount/input > /dev/null" and dividing; you
don't need anything fancy.  Make sure you -haven't- read "input"
on that machine, or that you know how to drop your caches, or
that "input" (which might be many files) is way bigger than your
available RAM.  Otherwise your block cache will bypass real I/O.)

If you're significantly under your raw bandwidth but it doesn't seem
like you can keep your CPU(s) busy, try running more than one job per
host.  That should allow one to soak up CPU while the other is waiting
for some packets.

Given the timings, you can rerun tests -without- transcoding by using
dd, pv, and nc to source/sink, throttle/monitor, and send/receive,
respectively, test traffic.  Then you can watch the stats as you add
machines or move them around or whatever, without waiting for entire
transcodes to finish or fail, etc.  I'd do that first, before doing
any real runs.

Also, do you have any nonstandard NFS mount parameters?  Don't set
actimeo=0, for instance.

I don't think precaching the files over NFS will particularly help
unless you're planning to read any given file more than once.  You
can't get any work done while the file is being cached, whereas it's
-possible- that the transcoder might actually prefetch a few packets,
or that I/O buffering may do it for you.  If that's not happening, run
multiple transcoding jobs.

The one case where precaching locally may help is if the transcoder
barfs if it can't read (or write) a packet in a timely fashion, and
especially if you then have to go in and manually reset things so it
can try again.  Issues with the wireless may lead to timeouts long
enough that the transcoder thinks it's lost the filesystem or gets I/O
errors etc; if those are frequent, that'll be annoying.  In that case,
you can write a simple shell script that rsyncs things over, with
retries either in rsync or via a loop around it, starts transcoding
once the file is there, and then tries to push its output back over
the wireless until that succeeds.  I'd try it the simple way unless
you get a nontrivial number of I/O-related transcoding failures.
[If you hard-mount, I expect you own't see such timeouts; whether
that's a good idea can be somewhat controversial.]