I've had similar problems with rsync. It is definitely sensitive to
large latencies.
I solved the problem by reducing txqueuelen to 0 on the eth if and also
on the vitual vpn if that talks to my router. This appeared to have
fixed the problem.
Various gurus have told me that reducing txqueuelen to 0 is NOT A GOOD
THING but what the hay, it works for me.
--Yan
Jason Haar wrote:
New development.
It does affect NT client as well as Linux rsync client. It just looks like
pure luck that the NT client didn't show the same symptoms sooner...
So to rewrite my original message...
We're trying to use rsync-2.4.5 (client and server) to replicate data over
a busy 128Kb Intercontinental Frame-Relay link from both NT and Linux
clients to a NT rsync server. It appears to work for a few connections - e.g.
rsync ntserver::
rsync -a dir ntserver::share/path
...but then on the 3-5 go, the NT rsync server will crash.
This same NT rsync server is being 100% happily used rsync'ing to other NT
clients over US-to-US T1 links, so this leads me to believe there is some
NT IP-stack issue that tickles a bug in rsync only when there are large
latencies (that's the only real difference I can come up with).
Sound possible? [I say it's a rsync bug as obviously other NT network apps
work fine over this link - maybe I should say "NT-specific rsync bug" :-)]
--
Cheers
Jason Haar
Unix/Network Specialist, Trimble NZ
Phone: +64 3 9635 377 Fax: +64 3 9635 417
