On Thu, Nov 06, 2003 at 06:08:28PM -0800, jw schultz wrote:
> I'm getting more and more convinced that --bwlimit should
> never have gotten into rsync. Bandwidth management belongs
> at the system level or let it be done with a common
> networking utility instead of at the individual utilities.
T
On Sat, 2003-11-08 at 03:29, Jason Philbrook wrote:
> I too like --bwlimit. It's not perfect, but it's so easy to adjust
> backup/restore speed in the backup program. We use rsync primarily for
> offsite backups, so it's great for planning bandwidth use over limited
> capacity links. For normal eve
> I'm getting more and more convinced that --bwlimit should
> never have gotten into rsync. Bandwidth management belongs
> at the system level or let it be done with a common
> networking utility instead of at the individual utilities.
I too like --bwlimit. It's not perfect, but it's so easy to a
> I rather like bwlimit... i suffer the same problem as Mikko
> in that I have a slow uplink. I haven't experienced his
> particular problem, though, and bwlimit seems to do its job well...
>
> Using some other networking tool or QOS just complicates the
> matter, and since rsync excels at d
Its just another vote for bwlimit
Since bwlimit was introduced with rsync 2.4.x it is doing for me its
job very well and was for me a very good enhancement of rsync.
thank you.
I rather like bwlimit... i suffer the same problem as Mikko in that I have a slow uplink. I haven't experienced his
I rather like bwlimit... i suffer the same problem as Mikko in that I have a slow
uplink. I haven't experienced his particular problem, though, and bwlimit seems to do
its job well...
Using some other networking tool or QOS just complicates the matter, and since rsync
excels at doing large tr
This again? Where 1024 was arbitrary not magic. This would
reduce the maximum throughput on a 100HZ system to
~100KB/sec no matter what the --bwlimit value is.
I'm getting more and more convinced that --bwlimit should
never have gotten into rsync. Bandwidth management belongs
at the system leve
Hello
I'm using a cable modem with a slow uplink, and therefore when I want to
transfer large amounts of data upstream, I tend to use rsync with
--bwlimit. However, the stock rsync seems to send a bit too much data at
once for comfort, momentarily blocking my meager upstream enough to
bother laten
On Wed, Jun 18, 2003 at 10:02:37PM +1000, Martin Pool wrote:
> On 15 May 2003, Paul Slootman <[EMAIL PROTECTED]> wrote:
>
> > I can't really see that doing smaller writes will lead to packets being
> > padded, unless you're doing really small writes (ref. the ATM 48-byte
> > packets); the TCP and
On 15 May 2003, Paul Slootman <[EMAIL PROTECTED]> wrote:
> I can't really see that doing smaller writes will lead to packets being
> padded, unless you're doing really small writes (ref. the ATM 48-byte
> packets); the TCP and IP headers will always be added, which means that
> the extra overhead
On 4 Feb 2003, jw schultz <[EMAIL PROTECTED]> wrote:
> Yes but i'd like to hear from some people who know network
> performance programming.
I know only enough to be mildly dangerous. :-)
I don't think you can do this optimally in userspace, because there is
lots of buffering between what we w
On Tue, Feb 04, 2003 at 11:06:26PM +0200, Mikko Rauhala wrote:
> On Mon, Feb 03, 2003, jw schultz wrote:
> > Just how magic is the 1024? To what was bwlimit set? And
> > the MTU?
>
> The 1024 is very magic, I just pulled it out of my hat and 'lo, it
> worked well enough so I didn't touch it.
I'
On Mon, Feb 03, 2003, jw schultz wrote:
> Just how magic is the 1024? To what was bwlimit set? And
> the MTU?
The 1024 is very magic, I just pulled it out of my hat and 'lo, it
worked well enough so I didn't touch it. I've usually used bwlimits of
4-12 depending on the time of day (expected avai
On Tue, Feb 04, 2003 at 03:06:05AM +0200, Mikko Rauhala wrote:
> Hello
>
> I'm using a cable modem with a slow uplink, and therefore when I want to
> transfer large amounts of data upstream, I tend to use rsync with
> --bwlimit. However, the stock rsync seems to send a bit too much data at
> once
Hello
I'm using a cable modem with a slow uplink, and therefore when I want to
transfer large amounts of data upstream, I tend to use rsync with
--bwlimit. However, the stock rsync seems to send a bit too much data at
once for comfort, momentarily blocking my meager upstream enough to
bother laten
15 matches
Mail list logo