Link to home
Start Free TrialLog in
Avatar of homerslmpson
homerslmpsonFlag for United States of America

asked on

Slow File Transfer Speed to/from Server 2003

We have 2 branch locations, one is BranchA and the other is BranchB.
I'm trying troubleshoot a file transfer issue we're experiencing and have noticed the following.

- Using a Windows 8.1 PC in BranchA, if I copy a 100MB file from the Desktop onto the C:\ of a Windows 7 PC in BranchB, it takes 25sec.

- Using a Windows 8.1 PC in BranchA, if I copy a 100MB file from the Desktop onto the C:\ of Server 2003 in BranchB, it takes 39sec.

- Using Windows 7 in BranchA, if I copy the 100MB file from the Desktop onto the C:\ of Server 2003 in BranchB, it takes 51sec.

- Using Server 2008 in BranchA, if I copy the 100MB file from the Desktop onto the C:\ of Server 2003 in BranchB, it takes 58sec.

- Using Windows 7 in BranchB, if I copy the 100MB file from the Desktop onto the C:\ of the WIndows 8.1 PC in BranchA, it takes 58sec.

- From Server 2003 in BranchB, browse to the Desktop of the Windows 8.1 PC in BranchA and copying/pasting the 100MB file onto the Server 2003 Desktop, it takes 1min 15sec.

- From Server 2003 in BranchB, browse to the Desktop of the Windows 7 PC in BranchA and copying/pasting the 100MB file onto the Server 2003 Desktop, it takes 1min 33sec.

Are there any settings or adjustments that can be made on Server 2003 and/or 2008 so that it doesn't take as long to send/receive files?

Any help would be appreciated.
Avatar of Sommerblink
Sommerblink
Flag of United States of America image

There were massive changes in how files are transferred via SMB between 2003 and 2008. You can read the technical details here: http://blogs.technet.com/b/markrussinovich/archive/2008/02/04/2826167.aspx. I didn't find such a through explanation between 2008 and 2012

Also, note that 2003 uses SMB 1.0, 2008/Windows 7 uses SMB 2.0 and 2012/Window 8 uses SMB 3.0. Given that, the probability to resolve this problem is slim given that the protocols are backwards compatible only.
Avatar of homerslmpson

ASKER

OK, the SMB issue makes sense.

The whole reason this came about is because of the speed issue we've been having in our 3rd branch which we will call BranchC.

In my original tests above, the second one was from my PC (W8.1) in BranchA to Server 2003 in BranchB which took 39sec.

I just did the same test but instead of going to BranchB I went to BranchC.  There's a huge difference in the amount of time it's taking.  From 39 seconds up to 1min 27sec!

Another example is in one of the last tests I posted above.
This involved connecting to the Server 2003 OS in BranchB, browsing to the Desktop of the Windows 7 PC in BranchA and copying/pasting the 100MB file onto the Server 2003 Desktop which took 1min 33sec.

I just did the same test but instead of using BranchB I used BranchC.  The speed took 2min 14sec!!

SonicWALL VPN tunnels are being used from branch to branch over cable connections.  Why is the speed so much slower in BranchC?
I am no networking expert, but have you confirmed that your network, from end to end has been set with the lowest common denominator MTU setting?

Example, BranchA and BranchB WAN connections allow a MTU setting of 1500, but BranchC has a DSL line that only supports 1492. You would want to configure ALL your network devices that talk to/from BranchC to 1492.

Furthermore, if you're using VPN technologies, the VPN encapsulation may cause fragmentation if you're MTU doesn't take into consideration the VPN overhead.

Easiest way to test is to use ping with the -l and -f flags. -l sets the size of the packet and -f sets the packet to do not fragment. The largest packet size would be 1500, and then decrease from there.

Fragmentation can cause these asymmetrical speeds, on top of the SMB version differences.
@Sommerblink -
Can you please give me an example of how I'd use this?
The subnet in BranchA is 192.168.1.xx
The subnet in BranchB is 192.168.2.xx
The subnet in BranchC is 192.168.3.xx
A cable connection is used in each branch.
Please explain to me when I'm trying to accomplish here.
@Nader Al-Kahtani - as much as I appreciate the help, copying/pasting a link isn't really all that helpful.

I took a look at the last link you provided and the command mentioned doesn't even run on my server running Server 2003 SP2. Even the Microsoft FixIt fails to install.
Sure.

So, we need to test fragmentation between each possible combination of network communication. Because the ICMP response from the destination is the data that the source originally sent, we really only need to test three different ways (as opposed to testing in each possible 'direction').

BranchA-BranchB
BranchB-BranchC
BranchC-BranchA

from A to B = ping -f -l 1500 192.168.2.1
from B to C = ping -f -l 1500 192.168.3.1
from C to A = ping -f -l 1500 192.168.1.1

The '-l 1500', this is the number that you will need to decrease until you stop seeing this type of response:
Packet needs to be fragmented but DF set.

For example, I would probably jump 50 bytes at a time until it passes a ping packet.
Then go half each time until you get it locked in.

For example, if I found that at 1350, it passed a packet, but not at 1400. My next intermediate step would be 1375. If that worked, then 1388. If it failed, 1363, so on and so forth until you get it.

If you discover that one network has a lower max packet size than the other two, you would need to follow the rule of lowest common denominator and use that setting across your entire network.

But before you really go and make changes to MTU across your network, I would test changing MTUs on just the test devices to see if performance goes up or stays the same.
Sorry, and the point of all this is that fragmentation of packets happens at the router. This consumes CPU and memory on the router for doing things that it ought not to do.

At the other end of the tunnel, the two packets now must be reassembled. Sometimes that is done by the receiving router and sometimes by the receiving computer. Either way, consumes more resources.
OK so here are the results:

from A to B = ping -f -l 1500 192.168.2.1
Reply from 192.168.2.1: bytes=1272 time=20ms TTL=64

from B to C = ping -f -l 1500 192.168.3.1
Reply from 192.168.3.1: bytes=1362 time=36ms TTL=64

from C to A = ping -f -l 1500 192.168.1.1
Reply from 192.168.1.1: bytes=1322 time=33ms TTL=64

So what does this mean and how can I test a possible solution?
Thanks!
So, silly question first - in the ping command, you still show a '-l 1500'. Is that just a copy/paste error, or was that the actual command and output?

Presuming it is just a copy/paste thing, the next step would be to change the MTU on your testing hosts. The MTU setting that you would want to pick is 1300. This is the smallest packet passed, 1272 + 28 (IP header size).

For modern operating systems, it's pretty easy. Please look at http://networking.nitecruzr.net/2007/11/setting-mtu-in-windows-vista.html on how to do it through command line.

For the ancient operating system, it requires modifying the registry directly: http://www.shogan.co.uk/windows-server/modify-your-nic-mtu-size-setting-in-windows-registry/

In essence, netsh does the same thing, just in a cleaner format.

Test your file transfers again to see if performance has been improved.

If it HAS - you now need to make a decision on whether or not to change the MTU across your network. This could cause problems with applications. Make sure for this test, you aren't making the changes on a production computer.

A very specific issue I am aware of is same subnet communication. If you have mismatched MTU settings for devices on the same subnet, there is no router in between the two devices to indicate that the packet is too large. In this instance, the computer receiving the too large of a packet will simply discard it. This means that it is not possible to simply change the setting on only your Server 2003 machines and leave the newer computers untouched, as the computers with the default MTU of 1500 may send packets which are too large for the modified computers. The modified computers will simply discard the oversized packets.

With a packet sniffer it is also possible to determine if the packets you're sending are getting fragmented by watching for the ICMP message "Packet too Large" coming back from the router. This could also ultimately help you decide if changing the MTU is ultimately warranted, regardless of the performance of the speed tests.
That was just a copy/paste thing.
I'm leaving for the day but tomorrow morning I will take a loo a the information you've provided and see if it helps.
Thanks!!
So I changed the MTU to 1300 using the registry on a spare server in BranchC and then rebooted the server.
The speed didn't increase. Still 1min 27sec to copy the file from my W8.1 PC in BranchA to the Server 2003 server in BranchC.
Any advice?
Yea, reverse back the MTU setting. :)

After doing some talking with a network guy, he and I both concluded that with one single exception, we both have never needed to modify the MTU anywhere for any client. The one example I had was with an IBM Bladecenter switch that ate the four bytes of VLAN tagging. In this example, the symptology was that we could load google.com's main page, but couldn't access any search results. Guess with their simple homepage, they never exceeded a fully loaded packet.

The technologies out there like Path MTU Discovery (PMTUD) to autodetect the MTU for a specific endpoint. Microsoft has supported pre-Windows 2003.

If you're interested in finding out what is happening, I would probably kick this request over to the Networking groups. Most likely it will require packet captures from both ends and what not to determine if you're being constrained by anything protocol related.

If you remember the entire network stack was rewritten for Vista/2008 to support IPv4/IPv6. Microsoft decided to greenfield it verses augmenting the old XP/2003 stack. There are a lot of optimizations that were put in place or defaulted to on (compared to prior versions) or were made more aggressive, such as sliding window protocols. That along with the revisions to the SMB protocol and how Windows File Caching works, I think that you'll likely find that the problem is simply with older technologies doing what older technologies were designed to do.

Good luck!
I was never able to figure out a solution to this issue.  I've spoken with SonicWALL support and they are placing the blame on the ISP stating that there is 2x the latency in BranchC and that's what would cause the speed to be 2x slower.
I don't know if that makes sense or not.
They suggested contacting our ISP.  Our ISP has already looked into this and they don't see anything wrong.
Sigh.
ASKER CERTIFIED SOLUTION
Avatar of Sommerblink
Sommerblink
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial