Re: Moving DR site from 30miles to 1600miles
- From: "Craig I. Hagan" <hagan@xxxxxxx>
- To: Mark Brinsmead <pythianbrinsmead@xxxxxxxxx>
- Date: Wed, 9 Apr 2008 22:42:42 -0400 (EDT)
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.
-- craig
--
//www.freelists.org/webpage/oracle-l
Other related posts:
