I've seen this problem mentioned many times in the various FAQs and
How-Tos on the Internet, but none of the solutions presented therein
have worked for me.
[global]
workgroup = UNIX
server string = OPTIMUS
interfaces = eth0
log level = 1
log file = /var/log/samba/%m.log
max log size = 0
# socket options = TCP_NODELAY SO_RCVBUF=4096 SO_SNDBUF=4096
# socket options = TCP_NODELAY SO_RCVBUF=65536 SO_SNDBUF=65536
# socket options = TCP_NODELAY SO_RCVBUF=262144 SO_SNDBUF=262144
socket options = TCP_NODELAY SO_RCVBUF=524288 SO_SNDBUF=524288
# socket options = TCP_NODELAY SO_RCVBUF=1048576 SO_SNDBUF=1048576
domain logons = Yes
os level = 65
preferred master = Yes
domain master = Yes
wins support = Yes
ldap ssl = no
admin users = root
hosts allow = 192.168.1.
getwd cache = yes
lpq cache = 30
use sendfile = yes
dnsproxy = no
netbios name = xxxxxxx
oplocks = yes
I started out with the default configuration and tried all the commented
out socket options. The 512k buffer about doubled my speed but my test
file transfer (700Mb file) is still much faster under ftp than samba. I
transfer my test file in 24 seconds under ftp and 2-4 minutes under samba.
Both interfaces are on both computers are fine and the duplex settings
are correct and error free.
I tried removing the *.tdb files, no help.
This gigabit connection should always be performing as it does under
ftp, any advice?
Yoink wrote:> I've seen this problem mentioned many times in the various FAQs and > How-Tos on the Internet, but none of the solutions presented therein > have worked for me. > > SNIP > > This gigabit connection should always be performing as it does under > ftp, any advice? >I copied a 600MB file from my workstation to our Samba server and it took approximately two minutes. I copied the same file from the Samba server to my workstation using the Command prompt and it took roughly 1 minute 30 seconds. This was done with the Samba server acting as a Primary Domain Controller and with the workstation joined to the Domain. I just performed the above unscientific test about ten minutes ago. I had also performed this test when I initially switched us off of a Windows server and onto the Linux server about 4 years ago and the Samba server provided file sharing significantly faster then our previous Windows server had. From my rather limited understanding, it simply won't be possible to get Samba to provide the same speed as FTP, due to the serious difference between the layers of software that are in between FTP serving files and Samba serving files. For instance, FTP provides no real security beyond the clear text password, while Windows Filesharing and Samba does. A better and far more accurate test would be to time the transfer of files from a Windows Server to a Windows Workstation, via Windows Filesharing and then from the Linux Samba server to the Windows workstation with all other variables being the same. Testing like things is far superior to testing unlike things. I believe that if you were to setup a FTP server on a Windows server and then copy a file off that server, it would also be significantly faster then using Windows filesharing. I could be wrong, as fine tuning networking speeds and testing servers isn't part of my job. Regards, Robert Adkins
Yoink wrote:> Robert Adkins wrote: >> Yoink wrote: > >>> This gigabit connection should always be performing as it does under >>> ftp, any advice? >>> >> >> I copied a 600MB file from my workstation to our Samba server and >> it took approximately two minutes. >> >> I copied the same file from the Samba server to my workstation >> using the Command prompt and it took roughly 1 minute 30 seconds. > > Well I should get -25% performance too, no? Mine is more like -400%.My test was very unscientific and it is very likely that copying the file took exactly the same amount of time whether I used the command line or the Windows GUI. I know nothing of the hardware, installation setup and other testing variables you have in place, such as the testing environment, in order to be able to answer your question. Again, I suggest that you test like things with like things, test a Windows server's file sharing and then Samba file sharing. Test FTP on a Windows server and then FTP on a Linux server and do this on a controlled network where only the workstation and the server are connected via one hub that has no other network connected to it. That way you can more clearly determine which is faster. I understand that there has been significant testing performed like the above and the last time I checked, which was more then a few years ago, Samba performed musch faster then Windows for file sharing. I do recall reading a more recent article (maybe 2 years back) that suggested Windows Server 2003 same closer if not equal to Samba in file serving speed. You would also have to look at other factors, such as the underlying file system used on your server. I have been assuming you are using Linux with Samba, if that is the case you could be using a variety of different file systems for your Linux partitions. For example, if you are using ReiserFS, then you would see a marked increase in reading/writing and subsequently file sharing for relatively small files in, I believe, the sub-32kb range as ReiserFS is tuned for sharing many small files very quickly. However, ReiserFS (At least the last version I was using) wasn't great for serving large files, like the 700MB test file you are using. From what I know of EXT3FS, it is a well rounded file system that is neither particularly fast nor particularly slow in serving files of various sizes. It is a good middle ground file system and the one that I primarily use on my servers and other Linux installations. Beyond that, there are numerous other factors that can lead to a slowdown in file sharing speeds, which is something that I am hardly an expert in determining. So, I am posting this back to the list, perhaps someone there will be able to better advise you towards what to look into. Regards, Robert Adkins
Blaine Armsterd wrote:> Robert Adkins wrote: >> Again, I suggest that you test like things with like things, test >> a Windows server's file sharing and then Samba file sharing. Test FTP >> on a Windows server and then FTP on a Linux server and do this on a >> controlled network where only the workstation and the server are >> connected via one hub that has no other network connected to it. That >> way you can more clearly determine which is faster. > > I tested the samve server and the same file over the same connection. > There's 2 boxes on the switch here at my house. There's no more > testing necessary. I can transfer the 723Mb file in 24 seconds using > FTP. There's no reason for Samba to take over 2 minutes.Samba and FTP both have vastly differing overheads that affect the transfer of files. Samba (and Windows Server's Filesharing) will never equal FTP in performance. Neither will even come close. FTP is an entirely different protocol that is extremely loose and insecure. You are talking about comparing Oranges to Chevy Trucks. They aren't the same besides the fact that Oranges are commonly round and Chevy Trucks commonly have Round Tires on them. Setup a Windows Server 2003 machine and test copying that file using Windows Filesharing and also using an FTP Server on the Windows Server. That is what I mean when I say test like with like. Compare the speed of the Windows machine in serving that file via FTP and compare that to the Linux machine serving FTP, then compare both in serving SMB/CIFS filesharing. That is the only logical, reasonable and true test that you will be able to make. Again, I am posting this back to the Samba list. I will *NOT* respond to you again. Regards, Robert Adkins
Rober Adkins wrote:> Blaine Armsterd wrote: >> Robert Adkins wrote: >>> Again, I suggest that you test like things with like things, test >>> a Windows server's file sharing and then Samba file sharing. Test FTP >>> on a Windows server and then FTP on a Linux server and do this on a >>> controlled network where only the workstation and the server are >>> connected via one hub that has no other network connected to it. That >>> way you can more clearly determine which is faster. >> >> I tested the samve server and the same file over the same connection. >> There's 2 boxes on the switch here at my house. There's no more >> testing necessary. I can transfer the 723Mb file in 24 seconds using >> FTP. There's no reason for Samba to take over 2 minutes. > Samba and FTP both have vastly differing overheads that affect the > transfer of files. Samba (and Windows Server's Filesharing) will never > equal FTP in performance. Neither will even come close. FTP is an > entirely different protocol that is extremely loose and insecure.As a matter of fact, In a properly set up network there should be no significant difference in speed between FTP and Samba WHEN transfering large files. For tests I usually open a DOS window, change to a share and just time the copy command in both directions with "timethis.exe", like this: C:\> W: W:\> dir aBigFile 31.08.2006 00:11 184.751.471 aBigFile W:\> timethis copy aBigFile C:\Temp 1 File(s) copied. Elapsed Time : 00:00:16.877 W:\> timethis copy C:\Temp\aBigFile 1 File(s) copied. Elapsed Time : 00:00:16.573 which means about 11 megabytes in either direction. FTP won't give you any better speed over a 100 Mbps link from PC to switch. Even If you connect to a gigabit switch through a proper gigabit NIC and a good cable the limit will be the speed of client's disks. A single disk can't give you more than about 50-60 meggabytes per second with either FTP or Samba. Robert Adkins wrote:> For example, if you are using ReiserFS, then you would see a marked > increase in reading/writing and subsequently file sharing for > relatively small files in, I believe, the sub-32kb range as ReiserFS > is tuned for sharing many small files very quickly. However, ReiserFS > (At least the last version I was using) wasn't great for serving large > files, like the 700MB test file you are using.Reiserfs 3.6 serves big files via Samba just as fine as small files. In all my tests the bounds are the throughput rate of the network and the ability of the client's mass storage to absorb and emit data, not the Samba software or the file system used. So to come to the point, if someone says his FTP transfers run 8x faster than Samba, then he/she actually means to say that his/her Samba server provides only 1/8th of the available power. This usually means that that person's network is not configured properly. Unfortunately, saying "ftp 8x faster than samba" is insufficient diagnostic to be able to pinpoint the problem. Even the addition in quoted mail that there are a server a client and a switch between them just scratches the surface. There's a lot more details we don't know about the setup. My guess is that there is a problem in name resolution. Blaine, do you get same transfer times when using IP-adress and unqualified name? I mean if your server's name is "samba" and its IP-address is let's say "192.168.1.1", do you get the same speed/slowness when you use \\192.168.1.1\yourShare as when you use \\samba\yourShare ?