Slow file copy

[sheess]

Hi all,

I have this incident where user is having a very slow transfer speed from one of our Data Center server going to another server in a remote DC location. We tried checking bandwidth utilization from all the links where the traffic travers and all are in normal condition. We also tried checking if there is any interfaces errors but we didn't detect any. Could you please help me with this one?

[Leo Laohoo]

One user is complaining of slow traffic originating from ONE source.  Is this correct?

[sheess]

Hi Leo, 

Yes,  he is copying files from an sql server in a Data center going to sql server in a remote data center. we also checked any dropped packets across the routers and layer 3 switch but there's no one occured. 

[MHM Cisco World]

No Drop but congestion in Queue effect that, 
check the TCP traffic, 
the TCP start send  small then large until one point the traffic start congestion avoide in Queue then TCP start send small again. 
this cycle is endless until you do something for your Queue. 

[Leo Laohoo]

---

@sheess wrote:
he is copying files from an sql server in a Data center going to sql server in a remote data center

---

Read and understand my question.  I am already providing hints. 

The issue is ONE person downloading from ONE server.  And that ONE person is claiming THE ENTIRE NETWORK IS SLOW. 

Slow down.  Think.  

1. Has anyone verified what that ONE person is saying? 
2. Has anyone tried to independently confirmed the issue from that ONE server? 
3. Has anyone tried to independently downloaded from A DIFFERENT server?

[sheess]

apparently, yes. we asked server team to do the same copy activity the end user did and the result was the same. when we asked the server team again to do the copy from the same source to a different destination (Data Center) the speed was very fast.

[Leo Laohoo]

---

@sheess wrote:
when we asked the server team again to do the copy from the same source to a different destination (Data Center) the speed was very fast.

---

Then the server team has answered their own question (and it is not "a network issue").

[ammahend]

Is this new issue ? If not then what changed ? Don’t want to jump to conclusion but In my experience most of slowness issue originate from fragmentation and can potentially be fixed by setting correct mss value on network side or mtu on endpoint itself . on the server side what the max mtu it can handle without fragmentation. Adjust the mtu on pc to match the server supported mtu and test again, see if it helps. 
here is a link to do that : https://docs.microsoft.com/en-us/answers/questions/535814/how-to-set-mtu-size-to-100-on-windows-10.html

[Joseph W. Doherty]

There can be lots of reasons.  If you have control over all links and interfaces end-to-end, and don't see interface drops or errors, along the path, both ways, that does often eliminate some possible issues.

One possibility, I don't think I've seen any other poster (yet) mentioned, if transfer is riding on/over TCP, TCP has its own issue when dealing with LFNs (long fat networks).  Insufficient information provided to give much of a clue of this being an issue beyond DC to DC (often "fat" [bandwidth]) and "remote" (possibly "long").

Search Internet on the subjects of LFNs and BDP ([TCP] bandwidth delay product).

[sheess]

Thanks Sir Joseph, I'll try this one.

[sheess]

do you think a device being on end of support stage has something to do with this? we checked the details of all the network devices the traffic took and we identified that one router is on its end of support stage.

[Joseph W. Doherty]

For TCP, a receiving host's RWIN, if too small for the BDP, will very much restrict transmission speed.  (As an example, years ago, I was working at a company the upgraded their trans-Atlantic bandwidth to decrease time to make database backups.  After bandwidth increase, they didn't see the throughput improvement they expected.  I told them to increase TCP RWIN on receiving hosts [which were Windows servers {which server folk went nuts with suggestion I wanted registry change - with reboot}].  They did make the change, and they immediately saw a 3x throughput jump.)

Without interface issues, you might find a software based router averaging near 100% CPU load, and if does, that will limit its throughput.  Further, if a Cisco router is forwarding in non-fast-path (i.e. process forwarding), that too will limit router's throughput capacity (also often drives CPU to 100% much, much sooner than fast-path/interrupt forwarding).

[Georg Pauwen]

Hello,

the issue could also be with the specific NIC(s) used in the server. Which brand/type/model do you have installed ?

[MHM Cisco World]

Friend check the interconnect link between two DC, the MTU must match the MTU of link connect to Server.