Stu,
I ran into similar circumstances when helping some folks transfer
data from FermiLab(Chicago) to Renater(France).
What options are you using for rsync?
The buffer tuning you refer to is actually tuning two different things.
The rsync TCP-buffer options allow you to set TCP buffers
We see absolutely dismal performance from Canberra to Perth via
Aarnet or Grangenet (gig connections across the country). With
standard rsync on a tuned tcp stack, we see about 700k/s. I started
playing with the --sockopts and have increased the performance to
1.4M/s which is better, but
Wayne Davison wrote:
>On Tue, Nov 01, 2005 at 09:55:06PM -0600, Lawrence D. Dunn wrote:
>
>
>>is it likely, or routine, or will-take-some-time, (or all-of-the-above),
>>for that patch to be vetted and integrated into mainline rsync released
>>code?
>>
>>
>
>I'm currently leaning towards inc
On Tue, Nov 01, 2005 at 09:55:06PM -0600, Lawrence D. Dunn wrote:
> is it likely, or routine, or will-take-some-time, (or all-of-the-above),
> for that patch to be vetted and integrated into mainline rsync released
> code?
I'm currently leaning towards including this in the next rsync release
unl
On Sat, Nov 05, 2005 at 10:18:24AM +0200, Shachar Shemesh wrote:
> Care to elaborate on the security implications? What is the potential
> for a DoS on someone giving out rsync services to basically untrusted
> parties?
I haven't thought it all through but one thing for sure is that larger
TCP buf
Jason,
Summary guess-on-my-part:
"Maybe" (w.r.t. will_larger_buffers_help?). Depending on which
satellite-height you're
using, and what your current default buffers are, and which-operating-system,
1-4Mbps is on the edge where more-than-default buffers are useful.
More detail below.
(
Can someone tell me if such options would help the likes of ourselves
with more "old fashion" linkspeeds?
We have 1-4Mbps VPN-over-Internet links (between continents - i.e. high
latency), and routinely find rsync only capable of 300Kbps - and rsync
is the best performer we can find. If we "par
Wayne Davison wrote:
>The patch also makes the new option accepted by the daemon's command-
>line parser, allowing whomever starts the daemon to override the config
>file's "socket option" settings via the command-line.
>
>
Care to elaborate on the security implications? What is the potential
fo
Wayne,
Wow- excellent!
Please help me understand what's "normal" for rsync development-
is it likely, or routine, or will-take-some-time, (or all-of-the-above),
for that patch to be vetted and integrated into mainline rsync released code?
I can see where this can be immediately useful
On Tue, Nov 01, 2005 at 01:03:39PM -0500, Lawrence D. Dunn wrote:
> I'd like to request/suggest that cli options to set TCP send/receive
> buffers be added to rsync client-side.
That's simple enough to do. The attached patch adds the option
--sockopts=OPTIONS that accepts the same option names as
Lawrence D. Dunn wrote:
>
> Renater was using rsync to pull large amounts of data from FermiLab
> across a fast,
> long link, and was getting poor throughput (~20mbits/sec).
Man - I wish I had your problem ;-)
--
Cheers
Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone
Dear rsync folks,
I'd like to request/suggest that cli options to set TCP send/receive buffers
be added to rsync client-side.
Summary:
I'm aware that a daemon's config-file can set socket options for
the server side
(e.g. SO_SNDBUF, SO_RCVBUF). That is useful.
But when trying to get
12 matches
Mail list logo
