Hei, I have stuggled to find any useful information on this topic so I wanted to raise it here (could it be that no one has noticed this phenomenon?)
I have a samba server instance sharing various volumes. Copying a file over my network results in approx 30MBytes/sec. For a long time I thought this was normal, but after an accidental use of a new Windows 7 based laptop (I turned it on before installing linux hehe) I see that it gets 80MBytes/sec!
Now since the server is the same, the wire is the same, machine same, switches same etc etc it must come down to the samba linux client.
I have read many things online (samba performance tuning) but nothing seems to affect the linux side performance (other than slowing it).
So 30MBs seems to be a linux limit. Could it be file system performance? no because copying a file locally is much faster (nfs over the network is also faster but lets not complicate things). Nothing I can think of seems to fit the bill unless the samba server side supports new windows extensions that the client side doesnt support (in my version).
For a laugh I shared a ram disk and copied from ram -> network cifs -> ram but still see 30MBs. The CPU usage is not dramatic so its not some strange linux CPU hogging problem causing the difference.
So I ask here, because I would like linux to be better and because I have no knowlege to find answers myself, why is the linux client so much slower (2.5 x) than windows when its against the same samba server?
Im not sure what information you need but I will try and list the obvious here.
:~$ cat /etc/samba/smb.conf
#======================= Global Settings =======================
workgroup = HOME
server string = My filesystems
dns proxy = no
log file = /var/log/samba/log.%m
max log size = 1000
syslog only = no
syslog = 0
panic action = /usr/share/samba/panic-action %d
security = user
encrypt passwords = true
passdb backend = tdbsam
obey pam restrictions = yes
unix password sync = yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
pam password change = yes
map to guest = bad user
unix extensions = yes
case sensative = yes
ea support = yes
load printers = no
printing = bsd
printcap name = /dev/null
disable spoolss = yes
show add printer wizard = no
########## Misc ################
#socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=65536 SO_SNDBUF=65536
# domain master = auto
[ media ]
comment = Media storage
path = /store/nonraid/media
valid users = @office @trusted user2
read only = yes
write list = @trusted user2
guest ok = no
oplocks = yes
browseable = yes
hide files = /lost+found/
map archive = no
Client side information (again sorry if it is incomplete):
fstab entry (current one, tried many performance options), even with defaults the speed is the same:
//myserver/media /store/services/smb/media cifs auto,uid=user2,gid=office,rsize=4096,wsize=4096,credentials=/etc/.cred 0 0
Since the exact same hardware is present in both fast and slow cases, I dont see a need to start listing detailed things from a performace perspective, also note that I get the same 30MB/s from my other multi core 7k SATA game system as I do with this new core i3 laptop. Even the SSD on my HTPC shows no difference.
OS Specific details.
Ubuntu 10.04 LTS (all updates applied as of today).
Laptop running Kubuntu, server running Ubuntu server.
I am really interested to at least find out why this would be and would welcome some feedback or simply ask for more information if needed. I am unable to test samba 3.5 because I do not have access to the packages for debian/ubuntu.
Thanks for reading.
Hi, Jeff! I think this is for you :-)
The difference here is the OS on the client side. The server isn't being changed -- is this correct?
You mentioned that you saw better performance while copying a file, but didn't say in which direction it was going. Were you copying the file to or from the share?
Hei, thank you for your interest in looking into this.
Yes your assumption is correct, the server does not change, same version. Also, the client side doesn't really change, it is the same Ubuntu version only the Kubuntu Desktop packaging.
File transfer speeds are consistently around 30MB/s from server to client and 22MB/s from client to server.
I have some more info today which I hope will help rather than confuse.
I tried the latest Beta of Ubuntu which uses samba 3.5.4 (I think) and 2.6.35-22-generic. Nothing changes here, same symptoms.
Client CPU usage is 6% for cifsd, 10% for kio-file so nothing spectacular.
Server side usage is smbd 14% and a second instance of 2%.
I thought about tracing with wireshark on Windows 7 and on the Linux OS. Is there a port I should trace (139?) or more than one?
Thanks for your interest.
*** Bug 7702 has been marked as a duplicate of this bug. ***
Things have been quiet for a while so I wanted to know if there any news here?
Is my problem recreatable or is it only me with this issue?
I suspect that you're just seeing the lack of parallelism in CIFS. Analysing captures may help determine that however. See this page for how to perform them:
I did some tracing and took a look at the capture. I noticed a packet size difference between a windows XP client and my linux client. Windows was recieving 64k packets and the linux client 16k packets. changing rsize=65536 in the mount didnt help due to the fact the cifs module uses smaller buffers. I added CIFSMaxBufSize=65536 and tried again. Now the traces both show 64k packets and Windows XP vs Linux Client is about equal! Both now do approx 35MB/s (still lower than windows 7 but so far so good). Parallelism between XP and linux seems about equal.
install cifs /sbin/modprobe --ignore-install cifs CIFSMaxBufSize=65536
remove cifs /sbin/modprobe -r cifs
//blah/files /media/files cifs auto,rsize=65536,credentials=/etc/.creds 0 0
The next step will be to follow up on Windows 7 since it is significantly faster (x2).
Question #1.3. Would it make sense to raise the default packet size in the cifs module since the performace difference is x2 when set to 64k? Is the memory usage so much more relative to a typical memory configuration today?
I will come back with the Windows 7 traces since I think this will need your eyes.
Just curious if there's been any progress on this bug? I'm having the same issues in Ubuntu 12.04.
This thread is also pertinent: http://www.overclockers.com/forums/showthread.php?t=683188
This should be much better in recent kernels. What kernel does ubuntu 12.04 ship?
Also, what mount options are you using on your cifs mount?
Just a short update: This issue is exactly as described above in Ubuntu 13.10 64 bit.
with recent kernels and smb3 the performance is much better