Hello, need some help solving this one...
We have 3 sites all connected via a T1 Private MPLS network. Pings are 20ms to the sites, but when copying files from site to site it is slow. Example 20MB file takes 3-4 mins.
I verified that there are no duplex mismatches.
Suggestions on where to start ?
Thanks,
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Save solutions to your questions, answers you’ve discovered through searching plus helpful articles in your personal knowledgebase for easy future access.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.
Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
I guess you already have an huge plan, but just wanted you to check for CRC errors on T1 link.
Ping will still give you good response time even if CRC errors are huge.
Have you used ping with a bigger packet. I suggest you to use FTP for file transfer speed test. FTP is build for file transfers, and you can quickly setup an FTP server using IIS.
But, yes don't forget to look for CRC errors on End points.
>Example 20MB file takes 3-4 mins
Even given completely optimal conditions (ie no other usage of the line), and saturating the line completely (which is hard to do), a 20MB file transferred at 150KB/s (typical T1 speed) will take at least slightly over 2 minutes to transfer. What makes you think your rates are particularly slow? If there's at least a bit of extra traffic over the circuits while you are transferring your data, then I think your rates are typical...
Cheers,
-Jon
I agree 100% with The--Captain. To add one thing to that is when you say "file copy" I am assuming you are using NETBIOS/SMB file sharing. NETBIOS/SMB has consideriable overhead.
For a test, setup a FTP server on one side. FTP a 20 MB file and see how long it take and see what the through-put rate ftp gets. Now generally I see 20-30% overhead added by NETBIOS/SMB compared to FTP. So take the time it took to transfer using FTP and add 20-30% and that is how long NETBIOS/SMB should take. Assuming that there is the same amount of other traffic to compete with.
How long did you expect it to take?
Here is a good site explaining in detail a lot of the SMB tuning parameters:
http://www.thincomputing.n
Cheers.
Business Accounts
Answer for Membership
by: infimatePosted on 2007-02-09 at 12:33:30ID: 18504322
The first step in troubleshooting slow file copies is to copy the file from the command line.
This will narrow the problem considerably.
This simple test will limit the number of components and protocols used and will also reduce network traffic so Network captures are easier to read.
File copies via the command line use the SMB protocol and the redirector component while File copies through the GUI use the redirector and the shell components.
Because the shell component is used during this action in the GUI, MSRPC traffic is generated.
Also Shell Extensions installed may have an affect with a test from the GUI.
If the file copy is slow from the command line we need to look at the following:
1. Network card driver and settings
2. Adapter/Protocol Binding Order and Providers/Provider Order
3. IP MTU size
4. TCP Layer Behavior
5. TCP retransmits
6. TCP acknowledgements
7. TCP window size
8. SMB Layer Behavior
9. SMB Read/Write size
1. Network Card Drivers and Network Card Settings
Update the NIC to the latest driver from the manufacturer. This seems simple, but this has fixed a large number of slow file copy cases. (Broadcom NICs are a frequent issue.)
Disable TCP and IP checksum offloading. This will cause this processing to be handled by our TCPIP stack instead of the Network card.
Set the Network Card and Switch from Autodetect to a hard coded link speed such as 100mb/half duplex.
2. Adapter/Protocol Binding Order and Provider Order
Verify that the NIC, protocol and provider used most often appears at the top of the list
3.IP MTU size may cause slow file copies:
Ethernet has an MTU size of 1500. RAS and VPN connections have smaller MTUs. Any hop in the path could cause the client or server to send smaller packets based on the lowest MTU in the path.
Test with the ping command with the -f and -l switches to determine the lowest MTU that works consistently from client to server. Start testing with:
ping Server IP –f –l 1472
This is based on Ethernet’s MTU of 1500 with 20 bytes subtracted for the IP header and 8 bytes for the ICMP header.
Move down from 1472 until you find the highest amount of data that will work consistently.
4. SMB Read and Write Size for a windows 2003 or XP computers
RegValue: SizReqBuf
RegKey: HKEY_LOCAL_MACHINE\SYSTEM\
Value Type: REG_DWORD
Valid Range: 512 to 65536
Try this and let me know us know if any further queries.