question for network professionals - slow file transfer speed, what to check?

Question

Hi I have a 3Gb file that transfers from one of our Dell servers through a 1Gb ethernet switch to a Cisco 3800 router over a 45Mbps DS-3 connection, to a Cisco 3700 router to a 100Mbps switch to another Dell Server. The transfer takes over 3 hours, which equates to around 1.5Mbps throughput (correct me if I'm wrong on the speed.)

I've checked all connections & none have errors or other obvious problems. Ping response times are relatively fast over all network connections. The sysadmin is using just the normal xcopy in a script to tranfer the files..he believes the problem is possibly with a bottleneck in the network (transitioning over multiple speed connections) but I think the problem may be with the protocol or with the servers. I should get at least 10Mbps xfer speed, right?

Any ideas on what to check next? Is there a better utility or command that can be scripted to run automatically? Is there a good/free utility to check file transfer speeds between two machines?

Answer 1

There are many things to check:

1. Match speed/duplex on all physical connections. A number of lousy network performance problems are traced to mismatched duplex between a server and a switch (half-duplex on one end, full-duplex on the other), such as after a power outage or rebooting a server. Auto-negotiation with network devices is similar to auto-negotiation with used-car salesmen. Set a fixed speed and full-duplex on each end of each connection you control (assuming each device supports full-duplex).

2. Check that your DS-3 connection really is a full DS-3. You may have a physical DS-3, but may only be paying for some fraction of the 45 megabit/second bandwidth. Is this a point-to-point DS-3 between the two sites, or is each site a DS-3 tail circuit into a virtual network cloud supporting multiple sites (frame-relay, ATM, MPLS, or something else), or are these DS-3 internet connections at each end? And if you are paying for a fractional DS-3, what happens when you exceed your subscribed bandwidth -- are you allowed to burst above the subscribed level or are your extra packets dumped?

3. Test your file transfer throughput at various times. Is the sysadmin kicking off this XCOPY with a scheduled script? Are other backup scripts running at the same time that run across the WAN?

4. Check that your gigabit switch is really a gigabit switch. Many vendors, including Cisco, sell switches that will connect to end stations at gigabit speed, but share electronics between multiple ports on the switch. The result is 'oversubscription' -- one station can sustain 1 gigabit/second throughput, as long as every other port on the same switch is doing practically nothing.

5. Try a less chatty transfer protocol. I remember using XCOPY on a drive letter mapping means you are using NetBIOS tranport on TCP (NBTCP). If you use Ethereal or another packet capture tool to sample the transfer, you'll may see your server only transfers three or four successive packets before expecting an ACK from the receiver. If you use ftp, a larger window may be negotiated, and your server may send more packets in a row before an ACK is required.

5. Work with your network folks to collect stats from the near-end and far-end routers to get an idea of how much of the WAN bandwidth is being used by your transfer, and how congested your WAN connection becomes while making this transfer. Read up on 'ip accounting' from Cisco IOS documentation, and see if a computer running MRTG can poll the routers via SNMP to generate some useful graphs on the bandwidth usage on the link, and if it pegs at a particular level.

6. One last possibility deals with jumbo frames. If your server and gigabit switch support jumbo frames, are they fragmented when they are sent across the WAN? If so, do all of your network control points support fragmented frames?



"Latency is not your friend" -- even if you have a full DS-3, if it takes a sizable fraction of a second to reach from near-end to far-end, you may spend a significant amount of time waiting for ACKs before your server sends more data. A fatter pipe won't fix high latency.

Answer 2

Many DS-3's are broken down by T1's , the reason I bring that up is a T1's thruput is 1.5M forget if its B or b now though.. bah Brain is fried anyway might want to check the interfaces on the ciscos and see if any of your interfaces has a speed listed. Those are the only things off the top of my head from what you posted.



My gut tells me its a layer 2 config issue but could be something wankie like a session mgr.

Answer 3

At DS-3 speeds that transfer could complete in about 9 minutes. Of course that assumes that there is NO other traffic on the link at all. You definitely have issues somehwere.



Windows will usually do a better job if you map the shares to a drive letter on both ends.

Answer 4

it might be because u have virus eating up all ur RAM n if ur transferring wirelesly that cud be the prob too using Ethernet cable is highly recommended n i'd like to give a small tip on this if u have pendrive 4GB is good jus transfer the files to that n connect to ur laptop n transfer whenever u want with speed (but this doesnt work all the time depends on ur file size too) hope this helped...