Samba file copy speed

30 11796
You are right about that there is something wrong. Samba on BananaPi can perform much better. But as tkaiser suggested, you should do more than a simple copy over network test to figure out the source of the problem.

When you copy a file from a windows machine over samba to your USB drive attached to your Banana Pi, there are serveral factors involved that could be the source of your problem. So, you have to test for each of them:
a) Your network throughput isn't as fast as it should be. In this case, samba can't be any faster even if your usb disk could go faster. That's what you test with iperf.
b) Your usb disk performance is too slow. In this case, even if the general network throughput and samba perform better, samba won't be able to write faster than the system can wrote to the disk.
c) Your samba configuration is not ideal. In this case, even if the disk and networt are fine, samba won't perform as fast as it could.

So, I suggest to run the usb write test as tkaiser proposed, just to make sure your usb disk is not the limiting factor here. I had cases where the same flash storage would perform well in one system, but horribly slow in another. In that case on would have to figure out, why that is and how it can be improved (choice of filesystem can make a difference here, just to give one example).

In general, I suggest you add at least those two lines to your smb.conf file (in the global section), as from my experience, they make quite some difference (if the underlying filesystem is fast enough):
  1. socket options = TCP_NODELAY IPTOS_LOWDELAY
  2. use sendfile = yes
Copy the Code
In a second step you can add these two lines as well and see if it makes a difference (it did for me, but not as much as the ones before):
  1. aio read size = 16384
  2. aio write size = 16384
Copy the Code
Make sure to restart samba (or the whole system) whenever you change the smb.conf file. For more tweaking options, please refer to the thread I linked before. But even without additional tweaks samba should perform much better, so that would go last for me.

I checked your smb.conf. While it looks minimalistic (especially security-wise), I suppose it should work. But I'm not sure if there are minimal requirements that you are missing, so better use testparm to see if you have syntax errors. On Debian I usually install samba this way:
  1. apt-get install samba samba-common samba-common-bin
Copy the Code
That includes a base smb.conf and testparm among other things.

Other than that, I would also suggest, you give Bananian another try, even if that means the effort of setting up the system again. The reason is that I never tried the Lubuntu image and even if most stuff should perform in a similar way, there could be something wrong with the image or configuration that we are not able to reproduce on Bananian.

Btw. just in case... When I wrote how to set up Logitech Media Server on Bananian, I might have forgotten one step: I'm not sure whether Bananian includes wget by default. In case it doesn't, run 'apt-get install wget' before attempting to download and install LMS.

Oh, btw. While I use robocopy over samba frequently, it doesn't make a huge difference for me. Especially large files should be way faster even if you use the Windows Explorer to copy files to your share.

Edited by mr_nick at Fri Nov 14, 2014 04:25

OK, I'll endeavour to work through ll of these steps to see if I can pinpoint where the problem lies but it still leaves me asking a few questions.

If the USB device is slow or network throughput is choked, how can robocopy hit such improved speeds?

My own severely uneducated way of thinking would say that surely if one system can attain high speeds then would it not be considered logical that the USB device can indeed write fast enough and the network can transmit fast enough?

Oh and just for completeness of information, the USB device is an externally powered Seagate 4TB drive but I have also tried with a couple of 16Gb flash drives and a USB powered WD 320Gb drive and all seem to give the same dismal explorer transfers and good robocopy transfers.

As  the first task, I added the suggested edits to the conf file and it looks like we may have success - transferring a 250Mb file via explorer took around 18 seconds.

I won't get too excited just yet and will do a few more file transfers to check that it wasn't just a fluke but fingers crossed!!

OK, I'm satisfied that this is now working properly. Transferring single files upto about 50Mb in size is so quick that I don't get a file copy progress bar showing up, a folder of an mp3 album takes around 3 seconds. Larger files (1Gb and over) are not quite so good but this is not an issue unique to this case - big files start out at about 60MB/second but then gradually slow down to about 10MB/second. This however is common to lots of people and it has been a bit of a bugbear at work where I need to transfer large files across the network and I get the same issue - and looking around the interweb, so do lots of other people.

But anyway, I think I can now close this case and say a massive thanks to you all for your invaluable help - I would never have got this one fixed without you. Very much appreciated.

Edited by tkaiser at Fri Nov 14, 2014 05:25
mr_nick replied at Fri Nov 14, 2014 05:05
OK, I'm satisfied that this is now working properly. Transferring single files upto about 50Mb in si ...

I know that you're not willing to do benchmarking or even structured testing 'from bottom to top' but it would be really nice if you could supply us with performance values measured with a benchmarking tool that does not just focus on sequential throughput and covers 'the whole setup' (client to server, both directions, network + storage -- this is always the last step after you measured each and every subsystem individually).

http://webshare.helios.de (user tools, passwd tools) --> Helios Tools --> HELIOS LanTest --> Windows

Might be interesting to get the results of "Fast networks" (test size 30 MB) and "Very fast networks" (test size 300 MB). Thx.

BTW: When dealing with strange network related problems there exists no such thing like 'common sense'. I had to investigate problems related to throughput in a customer's network that were related to the Explorer accessing shares over UNC paths or mapped network drives (\\server\foo\bar vs. G:\\foo\bar). At another customer the connection between client and server stalled for 2 minutes many times throughout the day: We found the reason in a totally unrelated name resolution quirk that affected two subnets that had nothing to do with SMB/CIFS at all (XP's SMB redirector also tried to connect the server from time to time via WebDAV -- still no idea why -- and these accesses over port 80 were redirected over an HTTP proxy and unless the proxy's default timeout led to an error message sent back the XP clients refused to do directory enumeration or copy stuff). And so on. Conclusion: Always test from bottom to top and avoid "if this then that"

It's not that I'm unwilling - more that I don't actually know or understand how to do it. But using a simple exe file is within my scope so here are the results of the LanTest.

mr_nick replied at Fri Nov 14, 2014 07:17
It's not that I'm unwilling - more that I don't actually know or understand how to do it. But using  ...

Thank you for providing the LANtest results. We're using Lantest since decades but since it has been ported to Windows just recently the results cannot be compared directly (we're solely Mac and Unix guys )

But normally it's a clear sign when the throughput with 300 MB test files decreases that much that these values are an indicator of an I/O bottleneck since the throughputs with 30 MB size are most likely the result of network/disk caches/buffers. Would be interesting if silentcreek could also provide Lantest results with identical settings since we walked through his setup in the past and came to the conclusion that the 30 MByte/sec his samba setup achieves are limited by USB2 after some network related tweaks.

Edited by mr_nick at Fri Nov 14, 2014 09:41

Just out of curiosity, I attached a SATA 128Gb SSD and then ran the LanTest on that drive to see how it compared to the USB drive. Speed is much better and I was able to transfer a 4.5Gb file in 2 minutes.


Thx for the SSD test. I collected some benchmarks in this thread. Maybe you gain more throughput by following the advices there?

So, I did some quick tests for comparison. See the attachments below. They seem a bit better to me, than I reach in real world use when I look at file transfers in Windows explorer (there it's usually about 28-30MB/s). I assume the last test run (Enterprise networks) is more realistic because at a size of 3000MB the effect of caching should be negletible.

Of course, as long as you're satisfied, there's no need to change or tweak anything. But it might be interesting to know what the Bananapi is capable of. Btw. I assumed you used a USB flash drive. That's why I asked about the speed tests. A normal USB hard drive is, of course, fast enough for the Bananapi. Yet, if you use a NTFS formatted drive, that might be a reason why the performance is not as expected.

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

Points Rules