File transfer by NFS very slow in Slackware client

arubin · 07-06-2008, 03:09 PM

I have
Slackware 12 running on a desktop
Slackware 12 running on a laptop
An Asus eee pc which comes installed with Xandros

Both laptop and Asus have the same set upfor NFS in fstab
Both show fast connections to the router with wireless.

But transferring files which take seconds with the Asus take many minutes with the laptop. Why is the Slackware laptop so much slower than the Asus?

1

Quote:

92.168.1.151:/home/ /home/user/nfs nfs ro,hard,intr 0 0

trickykid · 07-06-2008, 04:05 PM

Well, just displaying your fstab file will tell us nothing. What type of drive, memory, network connection? More details gets better replies.

Mr. C. · 07-06-2008, 04:25 PM

Pehaps IPv6 problems. Try disabling IPv6 if it is enabled (sorry, don't know slackware defaults).

Also, check link speeds. ifconfig -a

arubin · 07-06-2008, 04:33 PM

The desktop/server has an ext3 drive and 2GB RAM. It is connected directly to a BT homehub router
The laptop has ext3, 1GB RAM connects to the HomeHub by wireless
The Asus has an ext2 flash drive, 500MB and connects by wireless

Mr. C. · 07-06-2008, 04:49 PM

Try connecting the laptop vie wired Ethernet, and repeat your tests.

rvdboom · 07-07-2008, 03:30 AM

I have the same issue, so I'm definitely interested in your results.
BTW, I have a Ralink chip on the laptop to connect to the wifi router. Just to see if it could be similar to your settings.

arubin · 07-07-2008, 03:35 AM

I should add, if I had not made it clear that wireless access to the Internet from the laptop is not slow. I will try and get some proper figures when I have the opportunity. The situation is that with the laptop it is much quicker downloading a file off the Internet than it is downloading a file from my desktop/server. For the Asus downloading from either the Intenet or my desktop is fast.

tdos20 · 07-07-2008, 06:47 AM

have you checked out the nfs how to on getting good speeds - my nfs line in fstab has:

Code:

user,rw,hard,intr,rsize=16384,wsize=16384

as options and I get around 2Mb per second depending on interference using 802.11g

trickykid · 07-07-2008, 03:31 PM

Also this could depend on hard drive speeds. Most laptops are equipped with a 5400 RPM drive, the Asus Flash Drive could be that much faster to write, etc.

Also I see faster responses when I have DNS with proper resolution setup. You could add each host in your setup to each /etc/hosts with IP address to see if that resolves faster access and file transfer times.

arubin · 07-07-2008, 03:55 PM

I find it difficult to understand why hard drive speeds should make a difference.

I have just tried downloading a 7Mb file from the Internet to my laptop. That took 15 seconds. Downloading the same file from my desktop took 3 minutes 15 seconds.

arubin · 07-07-2008, 04:10 PM

It seems that tdos20 had it right. The same transfer takes 5 seconds with rsize=2048,wsize=2048.

Thanks

Mr. C. · 07-07-2008, 05:19 PM

If you are using NFS over UDP, read and write sizes have a significant impact, as lossy links will cause retransmissions of very large packets. For anyone wanting maximum performance from NFS, learning to use the various diagnostic tools is critical, as are comprehensive benchmarks with various permutations of NFS parameters.

Bruce Hill · 07-07-2008, 08:26 PM

Quote:

Originally Posted by arubin

It seems that tdos20 had it right. The same transfer takes 5 seconds with rsize=2048,wsize=2048.

Thanks

I don't know how you transferred that file, but for instance, if you
rsynced it (why would you transfer files any other way?) to and from the
same location, then that 5 second speed might be erroneous. An example:

Code:

eduardo@darkstar:~$ mount -t nfs
192.168.1.11:/backup2 on /server2 type nfs (rw,rsize=8192,wsize=8192,hard,intr,addr=192.168.1.11,nfsvers=3,proto=udp)

eduardo@darkstar:~$ cat /etc/fstab | grep server2
192.168.1.11:/backup2 /server2 nfs auto,rsize=8192,wsize=8192,hard,intr 0 0

eduardo@darkstar:~$ /sbin/iwconfig ath0
ath0      IEEE 802.11g  ESSID:"philemon"  Nickname:""
          Mode:Managed  Frequency:2.457 GHz  Access Point: <munged>
          Bit Rate:24 Mb/s   Tx-Power:20 dBm   Sensitivity=1/1
          Retry:off   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=58/70  Signal level=-32 dBm  Noise level=-90 dBm
          Rx invalid nwid:4  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

eduardo@darkstar:~$ rsync -va --progress /server2/kernel_source/linux-2.6.25.10.tar.bz2 .
sending incremental file list
linux-2.6.25.10.tar.bz2
    48614990 100%    1.48MB/s    0:00:31 (xfer#1, to-check=0/1)

sent 48621030 bytes  received 31 bytes  1543525.75 bytes/sec
total size is 48614990  speedup is 1.00

eduardo@darkstar:~$ rm linux-2.6.25.10.tar.bz2

eduardo@darkstar:~$ rsync -va --progress /server2/kernel_source/linux-2.6.25.10.tar.bz2 .
sending incremental file list
linux-2.6.25.10.tar.bz2
    48614990 100%   31.24MB/s    0:00:01 (xfer#1, to-check=0/1)

sent 48621030 bytes  received 31 bytes  19448424.40 bytes/sec
total size is 48614990  speedup is 1.00

I don't know why, but I do know that "rm" obviously leaves something cached.
Perhaps your results are from different tests and improved by changing mount
parameters, then unmounting and remounting your NFS share. I hope so.

Also, all wireless connections are not created equal. The laptop darkstar with user
eduardo is 50cm from the router. On the other hand, the laptop titus is in another
room, 6 meters from the router. And it's results:

Code:

mingdao@titus:~/kernel$ mount -t nfs
192.168.1.11:/backup2 on /server2 type nfs (rw,rsize=8192,wsize=8192,hard,intr,addr=192.168.1.11)

mingdao@titus:~/kernel$ cat /etc/fstab | grep server2
192.168.1.11:/backup2 /server2 nfs auto,rsize=8192,wsize=8192,hard,intr 0 0

mingdao@titus:~/kernel$ /sbin/iwconfig ath0
ath0      IEEE 802.11g  ESSID:"philemon"  Nickname:"titus"
          Mode:Managed  Frequency:2.457 GHz  Access Point: <munged>
          Bit Rate:36 Mb/s   Tx-Power:16 dBm   Sensitivity=1/1
          Retry:off   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=39/70  Signal level=-57 dBm  Noise level=-96 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

mingdao@titus:~/kernel$ rsync -va --progress /server2/kernel_source/linux-2.6.25.10.tar.bz2 .
sending incremental file list
linux-2.6.25.10.tar.bz2
    48614990 100%    2.21MB/s    0:00:20 (xfer#1, to-check=0/1)

sent 48621030 bytes  received 31 bytes  2261444.70 bytes/sec
total size is 48614990  speedup is 1.00

mingdao@titus:~/kernel$ rm linux-2.6.25.10.tar.bz2

mingdao@titus:~/kernel$ rsync -va --progress /server2/kernel_source/linux-2.6.25.10.tar.bz2 .
sending incremental file list
linux-2.6.25.10.tar.bz2
    48614990 100%   19.04MB/s    0:00:02 (xfer#1, to-check=0/1)

sent 48621030 bytes  received 31 bytes  19448424.40 bytes/sec
total size is 48614990  speedup is 1.00

Perhaps someone more knowledgeable, such as Mr. C., will address this.

I do see that darkstar is at 24Mb/s; titus at 36Mb/s -- atm I'm testing wicd on
darkstar, so there are no special parameters in /etc/rc.d/rc.inet1.conf.
In fact, afaict wicd is not yet ready for use by those who cannot edit
/etc/rc.d/rc.inet1.conf for particular APs. At least wicd does not work as
efficiently as the similar software used by Windows XP.

From reading some more about NFS, and optimizing settings, it seems that the
2.4.31 kernel on my server should be updated to 2.6.x.y.

Mr. C. · 07-07-2008, 09:21 PM

Use a more reliable set of tests to benchmark file transfers. Use iozone, bonnie, or bonnie++, a set of tests that are designed to defeat buffer cache issues.

Here's a good paper which discusses NFS performance and measurements.

http://www.iozone.org/docs/NFSClientPerf_revised.pdf

Bruce Hill · 07-07-2008, 09:29 PM

Yesterday I downloaded the bonnie++ source. When I have the time,
I'll build a Slackware package, install, and use it.