Long: Samba is slow - researched but cannot find
sessink at adsl-145-99-70-68.snelnet.nl
Thu Apr 29 11:01:46 GMT 1999
I have a Windows 95 machine 100TX-connected to a Linux samba. Speed is
extremely slow: about 1500Mbit per second. FTP-transfers show a normal
throughput: about 40 to 50 Mbit (which is normal, considering the
hardware). Please keep this in mind: ftp speed is _fast_ all the time,
so actually the hardware testing, tcp windowing stuff and all make no
sense (still, I tried).
Now _this_ is not your problem. The problem is, however, that a couple
of other messages in comp.protocols.smb showed the same bad performance,
with Linux and W95. I tried to figure out what's wrong, but have no
Linux 2.0.35/K6-300/96Mb (append "mem=96M": yes)/8Gb drive/Samba
2.0.3/3c905TX. I also tried 1.9.18p10; I also tried a SCSI disk instead
of the 8M IDE; tried a second IDE drive, too.
Win95/Cyrix P200+/48Mb/1.2Gb/SMC9432 100TX card. There used to be a
3c905TX inside, I changed it (just to check). Jaz disk, but I also tried
(Changed cables once, too. It's a cat5 cross cable).
Other problems I heard of talk about kernel 2.2.6, 10Mbit cards (speed
10-60Kb/sec :-( and machines with equal hardware.
smb.conf is quite normal:
domain master = yes
netbios name = slw
netbios aliases = bezemkast
local master = yes
preferred master = yes
workgroup = SNELNET
read prediction = true
read size = 8192
getwd cache = yes
debug level = 0
server string = "Diverse aanbiedingen."
os level = 92
security = share
wins support = no
wins server = 145.99.70.<WINS>
max log size = 100
interfaces = 145.99.70.<THIS ONE>/28 (netmask ends .240, that's why)
I also tried various socket options, such as both windows and
TCP_NODELAY. [Actually I think this "tcp_nodelay" should *not* be in the
"speed.txt" file, since it only disables Nagle (AFAIK), so this has
nothing to do with LAN-wide networks. Yes, TCP_NODELAY could help *a
little bit* if you're on a highly trustable WAN, but for regular
Samba-users, this option has nothing to do with speed *at all*].
OK, then I started to suspect TCP window size in Windows 95, and guess
what: the KnowledgeMaze has information about it: Windows ACK's every
other datagram, and also every (40ms I think) time another datagram
takes too long to receive.
I tried tcpdump to see if I ran out of tcp window size. But no: Windows
reacts as stated: ACK's were received right after sending 2 datagrams
(both 1460 bytes), so the (default) 8670 size was never used up. I
changed the SO_READSIZE (or how's it called) to 32something, and changed
the Windows 95 size to the same value, to no avail.
Windows 95 registry settings for tcp/ip:
smbd takes less than 5 % of the processor time, so that's not a problem
Anyone got a clue?
I'm not on the tech-list - hope that is not a problem.
Valentijn Sessink - valentyn&dds.nl
Email (o.; g.mv.) glasachtige, ondoorzichtige of transparante massa,
in een dunne laag aangebracht ter bedekking of versiering (brandverf)
van metalen, glazen en stenen voorwerpen en keramiek.
(Van Dale, 12e uitgave, 1992)
More information about the samba-technical