Les Mikesell wrote: > On 11/19/10 3:16 PM, Michael D. Berger wrote: >> On my intranet, I sometimes transfer large files, about 4G, >> to an CentOS old box that I use for a web server. I transfer >> with ftp or sftp. Usually, before the file is complete, the >> transfer "stalls". At that point, ping from the destination box >> to the router fails. I then deactivate the net interface on the >> destination box and then activate it. Ping is then successful, >> and the transfer is completed. The transferred file is correct, >> as verified with sha1sum. >> >> All connections are via cat6 wire. >> >> So what do you think? Should I try changing the net card? >> Any tests to run? Any other suggestions? > > I haven't seen anything like that, at least in many years so it probably is > hardware related - but make sure your software is up to date. As a workaround, > you might try using rsync with the --bwlimit option to limit the speed of the > transfer - and the -P option so you can restart a failed transfer from the point > it stalled on the last attempt. > This does ring a bell, but the circumstances were a bit different. In our case we were transferring large files between "home" and a remote site. SFTP/SCP transfers were stalling part-way through in an unpredictable manner. It turned out to be a bug in the selective acknowledgment functionality in the TCP stack. Short story, adding the following line to /etc/sysctl.conf fixed the issue: > net.ipv4.tcp_sack = 0 Of course, you can set it on-the-fly using the sysctl command: > sysctl -w net.ipv4.tcp_sack=0 It helped in our case, no way of telling if it will help you. As usual, your mileage may vary. -- Jay Leafey - jay.leafey at mindless.com Memphis, TN -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5529 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.centos.org/pipermail/centos/attachments/20101120/f79a32db/attachment-0005.bin>