I've been working with the Nvidia Jetson TK1 and the Parallella 16 for the past few weeks and during this time I noticed a delay or 'stuttering' on log file updates over the NFS connection between them.
This shows up in my "Driveby" application as a lack of 'responsive' updates on graphs and charts. During the past week I noticed if I would get on the NFS Client side (the Parallella) and would do something like 'tail -f /mnt/nfs/disk1/driveby_data/*mhz_data.out' (the data files being logged from RTL's to NFS from Parallella to the NFS server running on the TK1) that this delay or stuttering would stop and the graphs and live data would react immediately.
I'm posting this so that if you are trying to use NFS Server and Client setup and notice things are NOT updating immediately you'll know how to resolve it. This is NOT a Parallella or TK1 fault. This is a 'feature' built into NFS to improve performance and reduce cycles required to operate NFS.
At any rate the fix for my setup was to add some options to the NFS config and restart the NFS service then umount and mount the Client again. Fairly simple actually.
On the NFS server (Nvidia TK1) /etc/exports for my setup looks like this:
The addition was to add the 'no_wdelay' option.
then service nfs-kernel-server restart
On the NFS Client (Parallella 16) the /etc/fstab for my setup looks like this:
192.168.3.20:/ /mnt/nfs nfs rw,vers=4,hard,noac,intr,proto=tcp,noatime,nodiratime,rsize=8192,wsize=8192 0 0
The addition was to add the 'noac' option.
sudo umount /mnt/nfs
sudo mount -a
That's all there is to it. While NFS documention indicates there might be a performance hit on the server and client I'm not seeing one. Things are running at very acceptable loads and I don't see an increase running it like this vs. what it was doing before.
I just wanted to share this in case you ever need to keep NFS from lagging like my application requires.
Post a Comment