Re: Moving DR site from 30miles to 1600miles

From: Craig I. Hagan <>
Date: Wed, 9 Apr 2008 22:42:42 -0400 (EDT)
Message-ID: <>

> Silly question: how fast can you SCP a 1GB file locally? 50 MB/min (about
> 850KB/s) is far from "smoking" fast by todays standards, but SCP *can* be

a good host is constrained by the crypto speed/block checking. Disable that nonsense (there are patches) and you can get on the order of 60-80MB/s on a fast system. Use something like bbcp and you can easily get 117MB/s, which i routinely see for local copies. I can also readily max out many of the wan links i work with using it.

> pretty CPU intensive. Maybe 10 years ago, that was nearly as fast as you

depends upon the crypto algorithm. blowfish is the cheapest. for wan systems, it really comes down to # of bytes you can put on the wire. Scp doesn't currently shove enough out there in one go.

> You may also be affected by other factors. What is the latency on the link?

worst case is speed of light... that can be noticeable at higher speeds. but, for 1600 miles, I'd hazard on the order of 60-120ms depending upon the number of hops. Guess @ 90.

> Have you attempted transfers with another (simpler) protocol, like FTP or
> "netcat"?

may run into the same issue; how many bytes can a single thread slam on the wire. It is why I end up using multiple threads of transfer (max connections for dataguard) or a tranfer program which is implicitly handles multiple streams.

> I definitely like Jared's idea -- it is probably a good idea to have your
> network folks put a sniffer on the network, and analyze precisely what is
> happening with your transfer.

you likely can get 90% of the way there via tcpdump and following the negotiations. likely you'l see a negotiation and a window size that is less than the wiresize resulting in a bunch of packets being sent, some lag, then the acks come back; repeat.

Received on Wed Apr 09 2008 - 21:42:42 CDT

Original text of this message