[mythtv-users] NFS and remote backend

[R. G. Newbury]

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 
users,tcp,rsize=4096,wsize=4096,soft,intr,actimeo=0,nfsvers=3

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