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

[Stan Hoeppner]

Stan Hoeppner put forth on 1/23/2010 2:11 PM:

> 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:

I just did some additional testing to see how FTP would perform with full duplex
put/get to/from the xfs filesystem backing the Samba share for comparison to
Samba performance.  I used two sessions of the Windows 2000 inbuilt FTP command
line client with default settings.  I used the same 600MB+ file up/down, two
copies, different names.

full duplex get/put:
get ftp: 678624350 bytes received in 65.92Seconds 10294.35Kbytes/sec.
put ftp: 678624350 bytes sent in 89.88Seconds 7550.76Kbytes/sec.

one way get:
get ftp: 678624350 bytes received in 57.84Seconds 11731.97Kbytes/sec.

The up/down is very uneven with the concurrent ftp transfers, downloads
receiving more b/w than up.  ProFTPD doesn't balance or shape traffic by
default.  I looked into using mod_shaper but it's not compiled into the Debian
ProFTP daemon, and frankly I have no use for the traffic shaper beyond this
testing.  The headache of installing it or another ftp daemon which does shaping
is more hassle than it's worth at this point.

Anyway, as you can see from the numbers above, one transfer ran considerably
longer than the other as it received less b/w during concurrency, about 25
seconds, which artificially inflates its transfer rate a bit as it gets all
11MB/s of the b/w for the remainder of its transfer after the other transfer has
completed.  With that caveat mentioned, I'll point out that watching the output
of NetMeter during concurrency clearly showed a combined total of 16MB/s
up+down.  I ran the same test, same 600MB+ file, and traffic to/from Samba
averages only 13MB/s.  Remember, I'm reporting raw numbers, so protocol overhead
is irrelevant.

This testing demonstrates that due to one or multiple factors, hardware and/or
software, my combined maximum full duplex throughput between my Win2K
workstation and the Debian Lenny Samba server is approximately 16MB/s with my
fastest applications tested to date, those being FTP client and server.  Best
one-way performance achieved to date is the maximum for switched fast ethernet,
just over 11MB/s, obtained with FTP.

Full duplex performance maximization would be great, but frankly it doesn't
concern me as it is not one of my needs.  What is a need is maximizing one-way
single stream performance between the Samba server and my workstation.

So, again, what can I do to bring my single stream raw transfer Win2K<->Debian
Samba server performance up near the level of my FTP performance.  FTP
performance peaks at 11MB/s with a single stream yet SMB performance peaks at
only 8MB/s single stream.  Again, this is measuring raw packet performance on
the interface, so protocol overhead is already in the numbers.  Samba 3.2.5 or
Win2K, or the combination of the two, simply will not saturate the interface
with a single stream.  With two streams going the same direction, they _do_
saturate the interface at 11MB/s.

What's the solution to getting that last 3MB/s out of a single stream?  Or, put
a better way, that last 30% that's being left on the table.  From other posts
I've read here, people using GigE are also seeing something similar.  They can't
get that last 30% or so into the interface with a single stream.  I don't think
this problem is merely affecting me on Fast Ethernet.  I guess I really needed
the extra performance I could go buy some GigE cards (if they make them in
regular PCI) and a GigE switch.  However, I'd really just like to maximize what
I already have, and not go spending money I don't want to. ;)

-- 
Stan