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 |
2 Answers:
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: http://support.microsoft.com/kb/223140 answered 18 Feb '13, 23:15  SYN-bit ♦♦ |
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? Regards answered 18 Feb '13, 13:31  Kurt Knochner ♦ |
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.
did you use any capture filter that could have 'ignored' icmp?
O.K. to rule out a network problem not related to your file transfer protocol, I recommend to measure the connection with jperf (http://code.google.com/p/xjperf/).
You need two systems. One in X and one in Y. You need Java on those systems!
Then run these tests:
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, cloudshark.org, one click file hoster, etc.), so we can have a look ourselves.
Regards
Kurt