Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
rich, I had a similar problem that we tracked down to a duplex mismatch between all of the switch/router/firewall uplink ports and the server. basically, auto-negotiate is NOT your friend! we could transfer small files at expected speeds. as the file size approached 35 meg, the speed slowed, at 100 meg it crawled. watching the scp status bar, showed that the file started transferring, stopped and waited for an ungodly amount of time and then resumed the transfer. going through tons of logs we found some dropped packets. this occurred after we moved the server from outside the firewall to a DMZ. as part of our troubleshooting process we moved the server back outside and the transfers ran fine (it was then moved back into the dmz). eventually we found the duplex setting mismatch and all has been fine since then. hth. -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Rich Braun Sent: Thursday, January 03, 2008 10:46 PM To: [hidden email] Subject: Long scp transfers fail on dropped packet I'm having a bit of an argument with an online backup vendor about robustness of their application when transferring large files. Vendor: You're dropping too many packets. Rich: I can't reproduce this with anything less than 100MB of transfer. Vendor: You're dropping too many packets. Indeed, apparently I am dropping too many. A predecessor in my job had the same kind of run-in with Dell and Red Hat concerning drivers for the gigE interfaces on the 1950-class servers. I *think* that's where the packet loss (actually I think it's corruption) is occurring, at such a low rate (under 1 in 10,000) that the only application that can reproduce it is with utilities which rely on openssh, such as scp. My hunch is that the vendor is using openssh for its file transfers. I'm already well on the path of dumping the vendor anyway in favor of an on-site solution (I want to try bacula, but the learning curve is *immense*, it comes with a nice 800-page user manual!) but I'd like to get to the underlying problem if I can. Any thoughts on running scp for files over 2GB or so, in real-world networks that run on systems with flaky gigE drivers? (Tried reducing port speed to 100/full, doesn't help.) -rich P.S. Do you use bacula? Email me... -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ Discuss mailing list [hidden email] http://lists.blu.org/mailman/listinfo/discuss -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ Discuss mailing list [hidden email] http://lists.blu.org/mailman/listinfo/discuss
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |