Yes, NetApp's TCP implemention leaves much to be desired over WAN links. We had many long conversations with NetApp engineering, including tracking down a major bug with window scaling.
We found a substatial improvement when switching to ICS (i.e. use multi(src,dest)(src,dest) even with single end points). Apparently when using ICS it uses a different internal network stack/interface which is much better over the WAN. It still wasn't as good as our interim hack of proxying snapmirror connections via local Linux boxes (with their modern TCP stacks), but it ended up being good enough. WAN accelerators helped us greatly too.
--Dave
On Wed, Jun 4, 2008 at 12:58 PM, John Stoffel john.stoffel@taec.toshiba.com wrote:
Glenn> You can always try adjusting the wsize of the snapmirror Glenn> connection over WAN. Could help...
Nope, doesn't help. The default snapmirror tcp_window_size is already 2mb, which *should* be enough for my site, but doesn't do a damm thing to help.
Again, if you have a WAN link with high latency and high bandwidth, snapmirror/snapvault both suck in my experience. Which is why I'm spending my time doing lrep's by hand to rebuild DR snapvaults.
Friggin sucks...