On 22 Jun 2001, David Bolen <[EMAIL PROTECTED]> wrote:
> Dave Dykstra [[EMAIL PROTECTED]]
>
> > That level of the network is completely outside of rsync's control; if
> > you're using -e ssh, do you have problems when you use ssh by itself?
>
> Note that while rsync is certainly above this level of the network,
> asymmetric routes are notorious for causing significant issues with
> TCP flow control if their latencies happen to differ significantly -
> often decreasing throughput and adversely interacting with TCP slow
> start and congestion control mechanisms.
Another way in which routing differences could cause problems at this
level is different MTU sizes over some link. As Dave said, rsync is
very likely to cause SSH to generate maximum-sized segments, which
could cause a jam if the network is dropping packets above a certain
size rather than fragmenting them, or if a firewall drops fragments,
or if one machine is trying to do path MTU discovery but the ICMP
messages are lost or misinterpreted.
I can think of two solutions, neither terribly scientific:
a) run a network sniffer at one end and look for ICMP must fragment,
or IP fragments.
b) just turn the MTU down on both boxes and see if that fixes it:
On Linux:
# ip link set eth 500
or
# ifconfig eth0 mtu 500
Do other bulk transfers work? What about pings with large payloads?
Are there packet filtering rules at any point?
--
Martin
VA Linux Systems GnuPG encrypted email preferred
PGP signature
