samba - Jan 2010 - single stream performance issue, Win2K, WinXP, Samba 3.2.5-4lenny7 (Debian Lenny)

Hello fellow Samba users and devs.  This is my first post.  I've searched
documentation far and wide for Windows, Linux, and Samba, and have not been able
to shed any light on this issue.

I can't get more than 8MB/s during a single file copy stream out of my Samba
server over my 100FDX switched network either from Win2K or WinXP (I don't
have
a *nix client to test with).  The network is idle during testing.  Via FTP on
these Win machines to/from the same filesystem (100GB XFS) as the Samba share I
consistently get just a shade over 11MB/s.  However, if I launch two
simultaneous file copy streams from Windows Explorer or from the command line, I
hit the 11MB/s I see via FTP.  Interestingly, if I launch a file copy with the
source file being on one smb share on the server, and the destination being
another smb share (separate filesystem) on the server, the combined throughput
is also 8MB/s, 4 up and 4 down, which is very strange as this should be two
distinct streams.  I can copy files between the Win2K and WinXP machines at just
over 10MB/s in a single stream and max out the 11MB/s with two streams.

I've tweaked every relevant Windows registry setting I can identify, and
I've
tried all combination of the following smb.conf settings with various buffer
sizes

max xmit = 65535
socket options = TCP_NODELAY
socket options = SO_SNDBUF=262144 SO_RCVBUF=262144
socket options = IPTOS_LOWDELAY

and none of these tweaks make a difference.  Still only 8MB/s with a single
stream.

I've eliminated the network hardware and any CPU/mem/disk bottlenecks on the
server and workstations as possible causes.  The machines are all much more
powerful than the minimums required to fully saturate a 100FDX network.

I don't know if the problem lies with the Windows clients or with smbd.  The
one
thing that is certain is that this is a single stream performance issue.
Launching multiple copy streams maxes the network just as FTP does.  Why is
3MB/s of free bandwidth being left on the table for single stream operations to
from smbd?

Any/all hints comments are welcome.  I've burned many hours on trying to
figure
this out to no avail, and if I had any hair I'm sure I'd have pulled
much of it
out troubleshooting this. ;)  I'd really like to max out that single stream
performance.

Thanks.

-- 
Stan

Hello Stan,

Friday, January 22, 2010, 2:26:41 AM, you 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.

 FTP is a different protocol. You might find the answer if you look at
 the percentage the carrying protocol like SAMBA consumes out of the
 traffic to support protocol integrity. You may find out that the rest 2Mb
 (you should actually have no more than 10Mb/s at 100Mb interface) are
 used by the carrying protocol itself. That somehow "though the protocol
 itself allows" but "for the sake of connectivity" the maximum
size of
 the packet is set to 64?. Which is not surprising as far as Microsoft goes.

 I'm sure people around here might provide you with some data
 about SAMBA efficiency, but just remembering what a big difference
 1000Mb Ethernet produces over 100Mb as far as SAMBA is concerned -
 well my best guess it's not more that 80% of all traffic. 20% goes
 for protocol support.

SH> hit the 11MB/s I see via FTP.  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 can copy files between the Win2K and WinXP machines
at just
SH> over 10MB/s in a single stream and max out the 11MB/s with two streams.


-- 
www.rol.ru
Best regards,
 Igor                            mailto:sprog at online.ru

Hello Stan,

Friday, January 22, 2010, 2:26:41 AM, you wrote:


Check it out, I found it with google:

http://oreilly.com/catalog/samba/chapter/book/appb.pdf

You see "out of the box" there is about 20% difference between SMB and
FTP performance which corresponds with your experience.



SH> Hello fellow Samba users and devs.  This is my first post.  I've
searched
SH> documentation far and wide for Windows, Linux, and Samba, and have not
been able
SH> to shed any light on this issue.

SH> I can't get more than 8MB/s during a single file copy stream out of
my Samba
SH> server over my 100FDX switched network either from Win2K or WinXP (I
don't have
SH> a *nix client to test with).  The network is idle during testing.  Via
FTP on
SH> these Win machines to/from the same filesystem (100GB XFS) as the Samba
share I
SH> consistently get just a shade over 11MB/s.  However, if I launch two
SH> simultaneous file copy streams from Windows Explorer or from the command
line, I
SH> hit the 11MB/s I see via FTP.  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 can copy files between the Win2K and WinXP machines
at just
SH> over 10MB/s in a single stream and max out the 11MB/s with two streams.

SH> I've tweaked every relevant Windows registry setting I can identify,
and I've
SH> tried all combination of the following smb.conf settings with various
buffer sizes

SH> max xmit = 65535
SH> socket options = TCP_NODELAY
SH> socket options = SO_SNDBUF=262144 SO_RCVBUF=262144
SH> socket options = IPTOS_LOWDELAY

SH> and none of these tweaks make a difference.  Still only 8MB/s with a
single stream.

SH> I've eliminated the network hardware and any CPU/mem/disk bottlenecks
on the
SH> server and workstations as possible causes.  The machines are all much
more
SH> powerful than the minimums required to fully saturate a 100FDX network.

SH> I don't know if the problem lies with the Windows clients or with
smbd.  The one
SH> thing that is certain is that this is a single stream performance issue.
SH> Launching multiple copy streams maxes the network just as FTP does.  Why
is
SH> 3MB/s of free bandwidth being left on the table for single stream
operations to
SH> from smbd?

SH> Any/all hints comments are welcome.  I've burned many hours on trying
to figure
SH> this out to no avail, and if I had any hair I'm sure I'd have
pulled much of it
SH> out troubleshooting this. ;)  I'd really like to max out that single
stream
SH> performance.

SH> Thanks.

SH> -- 
SH> Stan



-- 
www.rol.ru
Best regards,
 Igor                            mailto:sprog at online.ru

Volker Lendecke put forth on 1/24/2010 5:04 AM:
> On Sat, Jan 23, 2010 at 02:11:04PM -0600, Stan Hoeppner wrote:
>> 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.
> 
> Just a quick hint: Single stream performance really heavily
> depends on the concrete client behaviour. smbclient from 3.2
> and higher should give you good performance. And watch out
> which program on the Windows client you use to do the copy.
> xcopy, robocopy and the Windows explorer on some OS version
> give dramatically different results. The difference comes
> from overlapping requests or their absence.
I just tested xcopy with the previously mentioned 600MB+ file between my Win2K
Pro workstation and the WinXP workstation, single stream, both directions.  I
also did the same xcopy tests between the Win2K Pro workstation and the Samba
server.  The b/w results are identical to the previous Windows Explorer file
copy tests, 8MB/s up/down to Samba, and a little over 10MB/s up/down to the
WinXP machine.

Are overlapping requests the cause of the single stream performance issue here?
 If so, are overlapping requests something that is negotiated in the SMB
protocol between the hosts or is it statically configured, or something compiled
into the client code?  I.e. if overlapping requests is the issue, why do the two
Windows machines seem to do it correctly between themselves, but the
Windows/Samba combination does not?

Is there something I can manually configure on Win2K Pro to overlap requests
to/from Samba?

Thanks for the assistance, insight, and education.

-- 
Stan