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
>
