A local backup of a server created a 201.4GB file in under 40 minutes. Subsequently, a backup copy job took over a week to copy this data through a VPN to a remote site. I’d like to figure out how to reduce this time by increasing the efficiency of
the backup copy job. (I’d also like to improve my understanding of TCP to more effectively troubleshoot this type of issue.)

The ISP link for one of the two sites is only 10 Mbps, which sets the max possible throughput. If I could transfer 200GB at 10Mbps, this job would complete in under 44 hours. The average RTT from three pings is 42mS so I believe that the bandwidth *
delay product would be 52.3KB.

Packet captures show that the backup copy job utilizes six concurrent streams. With 1410B frame size, that’s 8.4KB so the pipe is only 16% full. Does this suggest that I should increase the number of streams to 36 to fill the pipe?

WireShark shows 20-24% DUP ACKs depending on which side of the link these are captured. Typically, for those segments that require a DUP ACK, there are less than a dozen but I found one #25. I presume these are caused by packets getting dropped but I
don’t have enough experience to know if this is wildly excessive or not. Is this the key to the poor transfer performance? Is the VPN likely the cause?

Please offer tuning suggestions and any information I’m apparently missing to solve this problem. THANKS!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)