Samba file copy speed

30 11797
I have just noticed that the speed only seems to be a problem going from Windows to Linux. Pulling files off the Linux box back to the Windows box is a very different story - the folder of mp3s that took 20 minutes to go from Windows to Linux took just about 3 seconds coming back the other way.

Ok, so several issues here:

1) I'm running Logitech Media Server, too. It works flawlessly on Bananian. The problem you encountered is that the repository you've been trying to use, doesn't exist (works only for x86-based systems). You have to download and install the debian installer package manually as you did on Lubuntu. In a console environment this can be easily done with:
  1. wget http://downloads.slimdevices.com/LogitechMediaServer_v7.8.0/logitechmediaserver_7.8.0_all.deb
  2. dpkg -i logitechmediaserver_7.8.0_all.deb
Copy the Code
(Assuming you want to use the latest stable release. You can change the url and filename for different versions.)

2) I never tested iperf for udp specifically. But I use Samba on Bananian and the speed is about 29-30MB/s from a Windows 7 client. My harddrive is connected via USB2 so this is the maximum for my setup. Before I tweaked the settings, the read speed was about 20% slower than writing, but there is a thread about optimizing the performance of Samba on Bananian:

3) Please post your smb.conf so we can understand your setup better. You can redact all the parts you think may contain sensitive information.

4) Since you seem to have problems with UDP packages, please add the following line to your smb.conf in the global section:
  1. smb ports = 445
Copy the Code
This will force Samba to use TCP connections. Note that with this line added there is no NetBIOS support, so you might have to connect to your samba shares using server ip instead of a hostname. So, entering something like \\\ into the address bar of Explorer will get you to your samba server (change the ip between the backslashes to the ip of your banana pi).
Do some tests and see how it performs. You can remove this line afterwards.

mr_nick replied at Thu Nov 13, 2014 07:40
I have just noticed that the speed only seems to be a problem going from Windows to Linux. Pulling f ...

Interesting. I know of a problem with "TCP delayed ACK" that can happen between more conservative TCP/IP stacks (like eg. OS X) and modern (recent Linux kernels, Solaris 9+) that only affects traffic on one direction (but not that much, usually you see a decrease by factor 10 and not 50 as in your case in case you're interested in details which I doubt ;) see here please http://www.jeremycole.com/blog/2010/01/13/delayed-ack-in-os-x-is-incomprehensible/)

Could you please post the output of "ifconfig eth0" and have a look whether the files /proc/sys/net/ipv4/tcp_default_delack_segs, /proc/sys/net/ipv4/tcp_default_delack_min and /proc/sys/net/ipv4/tcp_default_delack_max exist?

Edited by tkaiser at Thu Nov 13, 2014 08:49
silentcreek replied at Thu Nov 13, 2014 08:38
Since you seem to have problems with UDP packages

I just asked him to test iperf using UDP because sometimes you won't notice packet losses with TCP (due to one side of the transmission being the bottleneck and retransmissions therefore not really slowing down mayimum throughput). Using UDP you can notice this stuff: https://iperf.fr/#tuningudp

OK, well being as Bananian will work with LMS then I will certainly give that a revisit.

In terms of the questions:
My smb.conf is very basic at the moment while I've been trying to suss this problem:
workgroup = WORKGROUP
security = SHARE
netbios name = BananaBOX
guest account = root

path = /media/usb0/
public = yes
writable = yes
comment = smb share
printable = no
guest ok = yes

Adding smb ports = 445 to the conf file makes no difference to the speed - it only blocks the netbios access as you said it would.

ifconfig eth0 output is as below:
eth0      Link encap:Ethernet  HWaddr 02:4d:05:82:f4:9d
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::4d:5ff:fe82:f49d/64 Scopeink
          RX packets:5174 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4206 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:4722893 (4.5 MiB)  TX bytes:4984085 (4.7 MiB)
          Interrupt:117 Base address:0xc000

Edited by tkaiser at Thu Nov 13, 2014 09:30
mr_nick replied at Thu Nov 13, 2014 09:05
RX bytes:4722893 (4.5 MiB)  TX bytes:4984085 (4.7 MiB)

Uninteresting since this must have been directly after a reboot

Did you took notice of the huge difference in throughputs based on direction only using Samba (therefore measuring the performance of your disk also) or also testing 'plain network'?

tkaiser replied at Thu Nov 13, 2014 08:42
Interesting. I know of a problem with "TCP delayed ACK" that can happen between more conservative  ...

Sorry, forgot to give a response to the existence of the files - it's a no to all of them.

Also, while setting up samba and creating my conf file, when I tried to check the file using testparm I got this message:
command not found: testparm

Also, I have now got Bananian set up on a different card and have installed samba. I have again modified the conf file and when attempting to test it I get the message that testparm cannot be found.

Does this sound like there is an issue with the samba install as I believe testparm is meant to be a part of it? Two different Linux builds and the same error on both and the speed situation is exactly the same on the Bananian build too.

AFAIK testparm is part of the 'samba-common-bin' package (apt-get install...). You still haven't answered the questions what you're testing from Windows to Linux. Network or I/O+network?

Real I/O benchmarking should be done using different tools but this should be enough to write 2GByte to the USB disk without filesystem buffers/caches involved:
  1. cd /media/usb0/ && dd if=/dev/zero of=testfile bs=1024 count=2097152 oflag=direct
Copy the Code
If it's not finished within an hour, you can hit [ctrl]-[c] and know that there's a problem with write speeds on this USB device.

To be honest, I've not been doing any kind of benchmarking or testing of speed - it is simply that I 'know' it shouldn't take 20 minutes to copy 65Mb to the USB device on the Banana. This is the exact same device as I use on the Raspberry and on this device there is no speed issue - copying the same files to the same USB drive takes around 9 seconds. So this is why I am feeling that there is something amiss with either the Banana hardware or its software configuration because the network and the USB device operate in what I would see as a very acceptable manner (for my needs at least).

Edited by mr_nick at Fri Nov 14, 2014 00:43

Right, I'm not going to say I have solved this but I have at least got a workaround. Having spoken to one of the people from our work IT department, a self-professed Linux geek, he told me he has experienced a similar problem a couple of times and asked me to try using Robocopy to transfer the files from Windows to Linux. I did this and sure enough I get much better speeds - transferring 1215 files totalling 5.1Gb took 25 minutes with an average speed 206MB/minute. If I transfer smaller batches of files/folders then the speeds go much higher and in excess of 1000MB/minute. Quite some improvement over the initial figures.

The IT guy couldn't explain why this was happening, just that he had seen it happen a couple of times on his own networks in the past.

You have to log in before you can reply Login | Sign Up

Points Rules