Linux server 2.6.18-4-amd64 #1 SMP Thu May 10 01:01:58 UTC 2007 x86_64 GNU/Linux
ethernet link 100Mb
Network is checked by other protocols (ftp, nfs, scp)
When starting copying from a windows or OSX system it first starts normal ~ 60Mb/s
After a few seconds the speed drops from 60% towards 2,5% on a 100Mb link.
I think it is in some update that the problem starts. Or after I've upgraded from a x386 amd system towards a intel core duo cpu
I've tried almost every config change, but the original config worked okay for a few years.
Some other strange thing.
When a windows system is copying and it goes slow, I start copying a other large file (600MB) on an other system, and all of a sudden the slow connection on the first system speeds up...
I can see in the logging the following change happening, but it doesn't give me the sollution where to look at the moment:
[2007/08/16 01:35:53, 3] smbd/reply.c:send_file_readX(2649)
send_file_readX fnum=4827 max=61440 nread=61440
When it says : max=61440 and nread=61440 the copy goes fast.
But when the copy is slow, the number is about: 4096
This is the config:
workgroup = test
server string = %h test(Samba %v)
interfaces = ethx
bind interfaces only = Yes
obey pam restrictions = Yes
passdb backend = tdbsam
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n .
log level = 3
log file = /var/log/samba/log.default
max log size = 1000
time server = Yes
preferred master = Yes
dns proxy = Yes
wins support = Yes
ldap ssl = no
socket address = 127.0.0.1 10.x.x.x
panic action = /usr/share/samba/panic-action %d
invalid users = root
lpq command = %p
lprm command =
encrypt passwords = Yes
domain logons = Yes
netbios name = Samba on Linux
default service = data
local master = Yes
name resolve order = wins, lmhosts hosts bcast
domain master = yes
socket options = TCP_NODELAY
comment = Home Directories
read only = No
create mask = 0770
directory mask = 0770
Next test for bug 4889 is on the same server which runs samba.
I've started a windows environment within vmware.
When I copy the data (one file of 700MByte) via a samba share to the vmware session on the same server, I get a 1% load on a virtual 1Gb/s link which should be ~10Mbit which is faster compared to the copy from a external windows/osx system that tried to copy the data from the same samba share.
700Mbyte transfer in 11 minutes = ~ 8 Mbit/s
So with samba I get a faster result when I use a virtual network nic instead of via a real network card.
But I've also excluded this by copy the data via other protocols such as FTP or NFS with a result of 60Mbit/s.
I have a similar problem.
Linux smb1 2.6.19-gentoo-r5 #2 SMP Mon Sep 3 17:12:36 CEST 2007 x86_64 Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz GenuineIntel GNU/Linux
All other ftp, scp protocolls working fine.
If I copy some files (size is unimportant) from Windows XP to Samba the speed is fine about 8-9MB/sec. But if I copy from Samba share to Windows XP the speed dropped to 300-700KB/sec. Meanwhile this copy I start to run for example 'ls -lR /' on the Samba server file trasnfer speed up to 4MB/sec, when I stop 'ls -lR /' speed back to 300-500KB/sec.
So if there is some disk activity on the server the speed is better, but not as good as in write.
I tried another kernel versions, but not help for me. My smb.conf working fine similar 32bit Gentoo server, so I think there is some problem with 64bit system and Samba.
I was wrong with my previous test. The problem is not the Samba and 64bit. The real problem is the onboard Realtek RTL8111/8168B PCI Express Gigabit Ethernet controller. No disk activity was the reason of speed up, but the LAN activity of SSH console show 'ls -lR' text scroll. I disabled the onboard LAN and insert an Intel Pro100 LAN card and a problem is disappeared.
A have heard many problem with this type of onboard LAN card.
Maybe the kernel driver has some bug or with the Realtek RTL8111/8168B card something wrong. I dont know, but I will change the whole MB ASAP and I will choose another MB with NO Realtek LAN card.
Thanks for the update. Closing as "not our bug".