[mythtv-users] NFS and remote backend
adeffs.mythtv at gmail.com
Fri Jan 11 15:21:01 UTC 2008
On Jan 6, 2008 1:24 PM, R. G. Newbury <newbury at mandamus.org> wrote:
> Brian wrote:
> > jongi wrote:
> >> David Brodbeck wrote:
> >>> On Jan 1, 2008, at 8:31 AM, jongi wrote:
> >>>> Mike Barnard wrote:
> >>>>>> Both systems are F8 but the nfs is painfully slow between them. ftp
> >>>>>> though runs at over 1MB/s and nfs is nowhere near that speed.
> >> /etc/fstab
> >> 10.0.0.3:/nfs4exports/share1 /mnt/mythtv/media/ nfs rw
> >> /etc/exports
> >> /nfs4exports/share1/ *(rw,async,all_squash)
> > You can try by increasing the buffer size by adding rsize=$kb,wsize=$kb
> > in the options section where $kb is the amount of buffer in kilobytes.
> > IIRC, Linux kernels over 2.4 default to an 8k buffer. Maybe try 32k
> > ($kb=32768)?
> > I've found that SCP, NFS and Samba all operate at the same speed (pretty
> > much). I'm not sure how FTP speed places in that group. Maybe try a test
> > using SCP to isolate if it's a network problem or NFS problem?
> I think that any of these methods should run at nearly the same raw
> speed. It's the extras of overhead which slow some of them down.
> I picked up some pointers somewhere and this is what I use between my
> systems. This is the laptop nfs mounting the myth box. With this setup,
> my limiting factor is the wireless G rate if I am operating wireless, or
> the wire speed rate if plugged in.
> myth.whatever.net:/video /mnt/mythvid nfs
> Various settings affect all this.
> 1) The MTU setting is raised to 4160 in the Network Device settings.
> This is 64 bytes (overhead allowance) above the 4096, which are the
> send/receive buffer sizes. This is now the max 'packet' size. (I know
> its not really the packet size, but that's as good a concept as any for
> this use). This cuts down on comm overhead where tcpip has to chop and
> re-assemble chunks of bytes before sending them on the the system.
> The soft,intr are supposedly faster than the other choices...I cannot
> even remember exactly what they are.
> The actimeo=0 is important. This tells the system not to write the
> accesstime to the file on each access. This is a major time overhead on
> even read access to a file.
> I didn't benchmark this but it does help.
Geoff, if I use your rsize and wsize with an MTU of 9000 should that
be ok or will it cause excessive overhead as well?
Before you ask, read the FAQ!
then search the Wiki, and this list,
Mailinglist etiquette -
More information about the mythtv-users