[Samba] single stream performance issue, Win2K, WinXP, Samba 3.2.5-4lenny7 (Debian Lenny)

[Stan Hoeppner]

Learner Study put forth on 1/23/2010 3:31 AM:
> Hi Linda:
> 
> Looking at some internet resources, it appears that both encryption
> and packet signing are off by default. Can u pls let me know how to
> disable these on samba server side (on 3.0.x)

Pretty sure they are both off in my case.  I did not enable them in smb.conf.

> On Sat, Jan 23, 2010 at 12:48 AM, Linda Walsh <samba at tlinx.org> wrote:
>> Igor wrote:
>>>
>>>  I don't find it strange at all. Your computer is acting as a traffic
>>>  proxy between two samba servers. If you have 100Mb network interface
>>>  your bandwidth should split exactly in two.
>>
>> ----        But he said he doesn't get a split in two when a win2k server
>> is used (he gets 11Mbps).    I.e. Two network streams in two different
>> directions should NOT halve throughput, _unless_ something is operating
>> in half-duplex mode.   "100Mbps, full duplex" should, _easily_,
>> allow two 8 MBps streams if they are going in opposite directions.

The 11MB/s was a different test, which I clearly stated.   It consisted of two
concurrent single stream file copies _from_ the Samba server _to_ a Win2K
workstation using standard Windows Explorer as the file copy program.  This test
saturated one leg of the 100FDX ethernet connection at ~11.5MB/s.

>> Stan wrote:
>>>
>>> Interestingly, if I launch a file copy with the SH> source file being
>>> on one smb share on the server, and the destination being SH> another
>>> smb share (separate filesystem) on the server, the combined throughput
>>> SH> is also 8MB/s, 4 up and 4 down, which is very strange as this
>>> should be two SH> distinct streams.
>>
>> ---
>>        I agree.  Is it possible your network device isn't running in FULL
>> duplex?

Absolutely not.  Both interfaces (Samba server and Win2K workstation) are
configured and confirmed to be operating in full duplex mode.  I confirmed this
by forcing the Win2k box to 100FDX.  This broke the switch which wants full
autonegotiation, forcing the link to half duplex.  It dropped performance by
over 60%.  I reenabled full autonegotiation, and performed a test which I had
not previously.  I launched two copy operations of the same ~600MB file, one up,
one down, and according to NetMeter, was running ~7.5MB/s up to the Samba server
and 6.5MB/s down to the workstation.  Combined this is 14MB/s, more than a HDX
link can provide.  I'm ashamed I can't get that close to the ideal 22MB/s.
There are two possibilities for this that I can think of:

1.  The two switches involved are soho/consumer class, both unmanaged.  One of
the two is a $10 Rosewill (no name Chinese) 8 port desktop jobby.  The other is
a circa 2003/4 SMC rack mount combo 8port 100FDX switch and firewall router,
which is a much better piece of gear, ran me about $100 in '03, but still pretty
low end.  The cost/quality of these two may or may not be a factor, but at this
point I assume it might be.

2.  The machines themselves may not be up to it, although I would think they
should be given their specs, and that we're talking about merely 100FDX with a
theoretical max of 12.5MB/s.

This is something I'll investigate further, after I figure out the single stream
problem.

>>        Other things to check (to optimize speed compared to ftp):
>>
>>        1) Ensure your communications are using TCP (port 445) and not
>> UDP (port 139).

For raw bandwidth maximization, what port and protocol are used won't make much
difference, if any.  In fact it shouldn't make _any_ difference in raw b/w.
Communications between the Samba server and Win2K client appear to be
exclusively over TCP 139 at this point according to netstat, instead I'm
misreading or looking in the wrong place.

Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN
tcp        0      0 192.168.100.9:139       192.168.100.53:1128     ESTABLISHED
udp        0      0 192.168.100.9:137       0.0.0.0:*
udp        0      0 0.0.0.0:137             0.0.0.0:*
udp        0      0 192.168.100.9:138       0.0.0.0:*
udp        0      0 0.0.0.0:138             0.0.0.0:*

>>        2) Ensure encryption (Sealing) is off.
>>        3) Ensure packet Signing is off.

I assume these are off by default.  I didn't enable them in smb.conf.

>> The overhead of 2 & 3 contribute to around a 15% performance hit according
>> to 1 MS source.  (Obviously turning such things off presumes you are on
>> a 'safe' network consistent with FTP usage, vs. SCP/SSH).

The network is private, thus safe in this context.  I'm pretty sure both of my
measuring tools are reporting raw bandwidth, iftop on Linux and NetMeter on
Windows 2000, so even if there is SMB overhead in the mix, it's irrelevant at
this point.  My problem is I can't max out single stream _raw_ bandwidth to/from
the Samba server.  I'm only getting 65Mb/s raw with a single file copy.  I get
92Mb/s with two concurrent operations going the same direction, same as with FTP.

>>        You need to make sure that, at least, one side has each of Sign and
>> Seal turned off and the other side has it set to 'no' or 'auto'.
>> If one side has 'require' set for the feature, and the other has the same
>> feature turned off, it will prohibit communications.

Yeah, pretty sure this isn't a factor since I do have communications. ;)

Thanks for your interest.  Maybe we can actually get this figured out before long.

--
Stan