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

[Stan Hoeppner]

Stan Hoeppner put forth on 1/25/2010 12:07 PM:
> Volker Lendecke put forth on 1/25/2010 1:28 AM:
>> On Mon, Jan 25, 2010 at 12:14:36AM -0600, Stan Hoeppner wrote:
>>> Volker Lendecke put forth on 1/24/2010 6:51 AM:
>>>> On Sun, Jan 24, 2010 at 02:09:51PM +0200, Michael Wood wrote:
>>>>> Except that he said "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 am assuming he used the same client in that test
>>>>> as he did with the test against Samba.  So from what he's said it
>>>>> seems that he gets more speed with a Windows server than with Samba
>>>>> for the same client.
>>>>
>>>> So what we need is a full network trace of both cases.
>>>
>>> Actually I'll give you something slightly different, and more to the original
>>> question.  I've taken two tcp captures on the Samba server machine.  Both
>>> transfers were performed using the Windows 2000 cli "copy" command pulling a
>>> 36MB avi file from a share on the Samba server.  The first test was a single
>>> stream copy.  The second test was a dual stream copy of the same file
>>> concurrently to two different destination directories.  I also had iftop running
>>> during the tests.  The single stream transfer maxed out at just over 64Mb/s.
>>> The dual stream test maxed out at 92Mb/s.  Following are the two tcpdump output
>>> files using "tcpdump -p -s 0 -w FILE port 445":
>>>
>>> http://www.hardwarefreak.com/smb_single_stream
>>> http://www.hardwarefreak.com/smb_dual_stream
>>
>> The dual-stream one is kindof limited help. The interesting
>> piece is how Win->Win does its thing faster, so we need to
>> see that one.
> 
> I think something is wrong.  I downloaded Wireshark Win32.  When running
> 
> tshark -p -w smb-winwin-single-stream port 445
> 
> the transfer rate is half what it is without Wireshark running.  What am I doing
> wrong?

This is rather interesting, and disheartening.  I've just spent 30 minutes
playing with tshark and windump.  For small file transfers, the presence of the
capture tools running cuts the network interface performance in half.  If I copy
a 600MB file, the rate gradually increases to 10MB/s but only after about 45
seconds.  Given my limited outbound, I doubt anyone wishes to try to download a
600MB file from my server, nor analyze the contents of such a behemoth.

What Windows capture tool is available that does not itself *cause* a further
performance problem in the act of capturing the data to solve one?  This is a
ridiculous situation.  This machine has a 2GHz AthlonXP CPU, 1GB RAM, and a
120GB 7200RPM IDE disk.  CPU for tshark or windump never exceeds 25%.  Why are
these capture tools doing this?  They've created a catch 22.  I can't report the
data without the capture, but the capture ruins the data.

This is very, very frustrating.  tcpdump on Debian has no such problems, and
that machine is a lowly dual 550 with only 384MB of PC100.  However, it's Linux
instead of Windows, which helps tremendously.  And, it's got an Intel Pro 100
server adapter in it whereas the workstation has an integrated nVidia nForce2
MCP 10/100 motherboard down NIC.

Please help alleviate the frustration here and get me back on the path to
solving this performance issue.

Thanks.

-- 
Stan