Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Long scp transfers fail on dropped packet



 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
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org