John,
Since you are running TCP 4.1, what version of VMS is running (6.x?).
1300 blocks in 50 sec is 650K/50s = 13KB/sec ~ 104Kbps
5000 blocks in 540 sec is 2500K/540 = 4.6KB/sec ~ 37Kbps
Time to transmit 5000 blocks at 13KB = 2500KB/13KB/SEC = 192 seconds
While fragmentation on the receiving end, could contribute to the delays, if seems unlikely that it would contribute 346 seconds in a 5000 block file, since we are just adding to the end of the file, and worst case, we would have something like 70 extension file headers (assuming 1 block cluster size and the unlucky event that each file extension is only able to get 1 block at a time). More likely would be some other disk activity at the time of the transfer (my opinion).
How long does it take to create a 5000 block file using something like this on the receiving end?
$ open/write testing123 test.dat
$ cnt = 0
$ write sys$output "Starting at ''f$time())'"
$ rec = f$fao("!508*z") ! 508 "z"s, with 2 byte VFC + 2 byte rec length, this is 1 rec per block
$_loop:
$ write/symbol testing123 rec
$ cnt = cnt + 1
$ if cnt .lt. 5000 then goto _loop
$ close testing123
$ write sys$output "Done at ''f$time()'"
$ exit
If that takes 346 seconds (or even 200) to run, then fragmentation may be a significant factor.
Given only the limited info you have provided, and assuming that the only variable is the size of the transfer, I think that traffic shaping is a good possible explanation. The transfer of the data in FTP is in a single FTP connection, and it is reasonably easy for routers to give lower priority to "bulk" traffic like FTP. I don't think that doing a ping to the other end while the transfer is in progress will necessarily give you an accurate indication of the limiting that the FTP is seeing, since ping normally uses ICMP packets, and these would not be treated as part of the FTP data.
The only reliable way to see rate limiting is with a protocol analyzer, like the free Wireshark.
Traffic shaping is similar in concept to the "priority adjusting" programs that lower priority of CPU hogs. FTP tends to use as much bandwidth as possible, and the packets are generally at the MTU. Traffic shaping tries to give the light users a break by letting them go to the front of the line. You may be able to get better performance by buying a better class of service, or possibly by trying to make your traffic look like something else, (encapsulation) or reduce the size of the files (zip) and make it a bunch of shorter TCP connections (trying to defeat traffic shaping) by splitting the file into more small pieces (zip followed by zipsplit). Depending on the traffic shaping, this may or may not have any effect, as it may be limiting based on source/destination ip, or may know that the multiple data connections are related to the same ftp control connection.
You could try an FTP to the null device, but you should probably watch the data with Wireshark while you do that to see if the rate gets throttled back as the transfer progresses.
Jon
it depends
