Prev: [Samba] samba 3.4 ldap sambaLogonTime update
Next: [Samba] Samba 2.2.7
From: Stan Hoeppner on 25 Jan 2010 15:00
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
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
From: Stan Hoeppner on 25 Jan 2010 18:40
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've been busting my but trying to get you something meaningful. This dump is
less than optimal for two reasons, but it's the best I can get you thus far.

1. Running tshark on Win2K creates a huge network performance hit and thus b/w
numbers for small file (<250MB) transfers don't come close to accurately
describing the real world. With tshark running the b/w is less than half of
normal with small files.

2. Because of this I had to do a huge file copy to allow time for the client to
level off at peak performance, which is still ~500KB/s lower than normal due to
tshark overhead.

Anyway, the file is over 400MB. It'll take quite a while to grab off my server.

http://www.hardwarefreak.com/smb-winwin-single-stream

Hope you are able to glean something meaningful from it.

--
Stan
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
From: Stan Hoeppner on 27 Jan 2010 17:40
Stan Hoeppner put forth on 1/25/2010 5:30 PM:
> Volker Lendecke put forth on 1/25/2010 1:28 AM:

>> 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've been busting my but trying to get you something meaningful. This dump is
> less than optimal for two reasons, but it's the best I can get you thus far.
>
> 1. Running tshark on Win2K creates a huge network performance hit and thus b/w
> numbers for small file (<250MB) transfers don't come close to accurately
> describing the real world. With tshark running the b/w is less than half of
> normal with small files.
>
> 2. Because of this I had to do a huge file copy to allow time for the client to
> level off at peak performance, which is still ~500KB/s lower than normal due to
> tshark overhead.
>
> Anyway, the file is over 400MB. It'll take quite a while to grab off my server.
>
> http://www.hardwarefreak.com/smb-winwin-single-stream
>
> Hope you are able to glean something meaningful from it.

Were you able to grab this trace file yet Volker? If so, have you found
anything interesting yet when comparing it to the previous Samba->Win2K trace
file? Any clues yet as to why the win-win throughput is almost 3MB/s better
than Samba->Win? If you haven't dug into it yet, as a reminder, this last trace
capture was done with tshark on windows. The previous trace file was captured
on the Linux machine with tcpdump.

--
Stan
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
From: Stan Hoeppner on 2 Feb 2010 08:50
Stan Hoeppner put forth on 1/27/2010 4:37 PM:
> Stan Hoeppner put forth on 1/25/2010 5:30 PM:
>> Volker Lendecke put forth on 1/25/2010 1:28 AM:
>
>>> 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've been busting my but trying to get you something meaningful. This dump is
>> less than optimal for two reasons, but it's the best I can get you thus far.
>>
>> 1. Running tshark on Win2K creates a huge network performance hit and thus b/w
>> numbers for small file (<250MB) transfers don't come close to accurately
>> describing the real world. With tshark running the b/w is less than half of
>> normal with small files.
>>
>> 2. Because of this I had to do a huge file copy to allow time for the client to
>> level off at peak performance, which is still ~500KB/s lower than normal due to
>> tshark overhead.
>>
>> Anyway, the file is over 400MB. It'll take quite a while to grab off my server.
>>
>> http://www.hardwarefreak.com/smb-winwin-single-stream
>>
>> Hope you are able to glean something meaningful from it.
>
> Were you able to grab this trace file yet Volker? If so, have you found
> anything interesting yet when comparing it to the previous Samba->Win2K trace
> file? Any clues yet as to why the win-win throughput is almost 3MB/s better
> than Samba->Win? If you haven't dug into it yet, as a reminder, this last trace
> capture was done with tshark on windows. The previous trace file was captured
> on the Linux machine with tcpdump.

Some additional data points to add to this performance issue. Using smbclient
3.2.5 on the samba server box, with no tweak options, I ran get/put tests to
each of the Windows workstations. The results are interesting to say the least.
The get performance maxes the fast ethernet link at ~11MB/s. If you recall,
the workstations max out their upload to smbd at ~8MB/s, with the same for
download. If smbclient on the smbd box can pull from a workstation at 11MB/s,
using the same TCP/IP stack and SO settings smbd should be able to absorb an
upload at 11MB/s because it's the same path. But it doesn't, it caps the
workstation uploads (and downloads) at ~8MB/s, no matter what options I try.

Windows XP Home machine:
smb: \> get src.exe
getting file \src.exe of size 121983488 as src.exe (11276.5 kb/s) (average
11276.5 kb/s)
smb: \> put src.exe
putting file src.exe as \src.exe (6149.3 kb/s) (average 6149.3 kb/s)

Windows 2000 Pro machine:
smb: \> get src.exe
getting file \src.exe of size 121983488 as src.exe (11195.9 kb/s) (average
11195.9 kb/s)
smb: \> put src.exe
putting file src.exe as \src.exe (6362.5 kb/s) (average 6362.5 kb/s)

--
Stan
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
First  |  Prev  | 
Pages: 1 2
Prev: [Samba] samba 3.4 ldap sambaLogonTime update
Next: [Samba] Samba 2.2.7