This is our old Q&A Site. Please post any new questions and answers at

We are having an issue where moving files from one office to another is drastically different. If the file is in office X, and I am transferring it to office Y, the process is much slower going from X to Y, then it is from Y to X. To give you an idea, from X to Y, Windows was showing an average speed of 800KB/sec. Going from Y to X with the same file, the transfer was about 6MB/sec.

When looking at the Wireshark data when I transfer in each direction, I noticed that in going from Y to X, the Request and Response occur right after one another. From X to Y, there are additional TCP packets being generated.

asked 18 Feb '13, 13:14

cnjbucks's gravatar image

accept rate: 0%

Since SMB is a block orientated protocol (and not stream orientated), there will be a roundtrip delay for each block. When transferring big files over a WAN, this delay can become substantial, as there will be many blocks.

When using NT explorer, for some unknown reason, the blocksize is different depending on the direction of the transfer. If you write a file to a remote system, the blocksize is 4K, when you read from a remote system it is 60K.

Solution: do the transfer in a command shell. See also:

permanent link

answered 18 Feb '13, 23:15

SYN-bit's gravatar image

SYN-bit ♦♦
accept rate: 20%

Without having any further information, one possible reason could be an MTU size problem when you copy from X -> Y. Do you see any ICMP "fragmentation needed" messages in the capture file? Do you have a VPN tunnel between X and Y?


permanent link

answered 18 Feb '13, 13:31

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
accept rate: 15%

Hi Kurt,

I don't see any ICMP messages in the capture file. I think there is a problem at site X that I have to figure out. Today I had a PC setup at another site (I'll call it site Z). I transferred the same file I was moving between X and Y between Y and Z, and the file transfers were noticeably faster.

This is not a VPN tunnel, this is going over our MPLS network from one office to another.

I noticed in the captures going from X to Y, I see the AndX Request and then several lines that show micrsoft ds --> 53367 [ACK]. From Y to X, I see the AndX Request and that is immediately followed by the AndX Response. I see this same behavior in the transfers I did today from Z to Y.

I did discover today that if I ping the storage at site Z from the switch that this storage is plugged into, the success on those pings was 968/1000.

(19 Feb '13, 14:05) cnjbucks

I don't see any ICMP messages in the capture file.

did you use any capture filter that could have 'ignored' icmp?

I transferred the same file I was moving between X and Y between Y and Z, and the file transfers were noticeably faster.

O.K. to rule out a network problem not related to your file transfer protocol, I recommend to measure the connection with jperf (

You need two systems. One in X and one in Y. You need Java on those systems!

Then run these tests:

X: jperf is client, Y: jperf is server
X: jperf is server, Y: jperf is client

Let the test run for ~ 30 seconds.

If there are notable differences in speed, then there is either a problem in the MPLS (possibly wrong QoS settings) or a problem with your network equipment (whatever that might be). In that case, please record the two tests with Wireshark (at both sides) and post the capture files somewhere (google docs,, one click file hoster, etc.), so we can have a look ourselves.


(19 Feb '13, 14:27) Kurt Knochner ♦
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 18 Feb '13, 13:14

question was seen: 7,073 times

last updated: 19 Feb '13, 14:27

p​o​w​e​r​e​d by O​S​Q​A