Solved

Slow File Transfer Speed to/from Server 2003

Posted on 2014-12-09
16
300 Views
Last Modified: 2014-12-26
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.
0
Comment
Question by:homerslmpson
  • 7
  • 7
  • 2
16 Comments
 
LVL 12

Expert Comment

by:Sommerblink
ID: 40489055
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.
0
 
LVL 1

Author Comment

by:homerslmpson
ID: 40489129
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?
0
 
LVL 12

Expert Comment

by:Sommerblink
ID: 40489234
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.
0
 
LVL 8

Expert Comment

by:nader alkahtani
ID: 40489284
0
 
LVL 1

Author Comment

by:homerslmpson
ID: 40489299
@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.
0
 
LVL 8

Expert Comment

by:nader alkahtani
ID: 40489377
0
 
LVL 1

Author Comment

by:homerslmpson
ID: 40489434
@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.
0
 
LVL 12

Expert Comment

by:Sommerblink
ID: 40489437
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.
0
How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

 
LVL 12

Expert Comment

by:Sommerblink
ID: 40489447
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.
0
 
LVL 1

Author Comment

by:homerslmpson
ID: 40489452
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!
0
 
LVL 12

Expert Comment

by:Sommerblink
ID: 40489605
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.
0
 
LVL 1

Author Comment

by:homerslmpson
ID: 40489638
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!!
0
 
LVL 1

Author Comment

by:homerslmpson
ID: 40493770
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?
0
 
LVL 12

Expert Comment

by:Sommerblink
ID: 40496704
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!
0
 
LVL 1

Author Comment

by:homerslmpson
ID: 40507587
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.
0
 
LVL 12

Accepted Solution

by:
Sommerblink earned 500 total points
ID: 40509260
If you want to test to see if it is latency related, you would need to perform a file transfer test between two of the same two operating system versions at each site. I would recommend using Windows 8 or 7 machines as your test bed since they are the latest and most optimized.

If you see a massive difference in speed between the three possible network location combinations, (A-B, B-C, C-A), and all other things are equal (wasn't much of any other traffic going through the WAN link at the time), then yes. Latency is probably a factor.

If you get similar speeds in the above test, but differences between operating systems versions, then the problem is most likely due to protocol fallback (SMB 1.0 verses 2.0 and 3.0) and network stack tuning (XP/2003 verses Vista and later).

Good luck.
0

Featured Post

6 Surprising Benefits of Threat Intelligence

All sorts of threat intelligence is available on the web. Intelligence you can learn from, and use to anticipate and prepare for future attacks.

Join & Write a Comment

This article is in response to a question (http://www.experts-exchange.com/Networking/Network_Management/Network_Analysis/Q_28230497.html) here at Experts Exchange. The Original Poster (OP) requires a utility that will accept a list of IP addresses …
A quick step-by-step overview of installing and configuring Carbonite Server Backup.
This video gives you a great overview about bandwidth monitoring with SNMP and WMI with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're looking for how to monitor bandwidth using netflow or packet s…
This video demonstrates how to create an example email signature rule for a department in a company using CodeTwo Exchange Rules. The signature will be inserted beneath users' latest emails in conversations and will be displayed in users' Sent Items…

705 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

19 Experts available now in Live!

Get 1:1 Help Now