On Thu, 14 Nov 2002 [EMAIL PROTECTED] wrote:
> Here's one of my setups. It's invoked from inetd.
> ...
> Good luck.
Thank you ! I'll try it, but maybe only from next monday on because
fridays are sometimes hard at work (users crying on fridays
extremely loud, maybe I shouldn't torture them that
On Thu, Nov 14, 2002 at 09:44:45PM +1100, Donovan Baarda wrote:
> On Wed, Nov 13, 2002 at 02:17:28AM -0800, jw schultz wrote:
> > While the receiver bears the brunt of the CPU work the
> > sender is hardly idle. Aside from generating the initial
>
> The reciever _doesn't_ bear the brunt of the CP
OTECTED]
Sent by: [EMAIL PROTECTED]
11/13/02 12:45 PM
Please respond to uwp
To: Tim Conway/LMT/SC/PHILIPS@AMEC
cc: [EMAIL PROTECTED]
<[EMAIL PROTECTED]>
Subject:Re: Speed problem
Classification:
On Wed, 13 Nov 2002 [EMAIL PROTECTED] wrote:
On Wed, Nov 13, 2002 at 02:17:28AM -0800, jw schultz wrote:
> On Wed, Nov 13, 2002 at 10:02:34AM +0100, [EMAIL PROTECTED] wrote:
> > On Tue, 12 Nov 2002, Wayne Davison wrote:
> >
> > > On Tue, Nov 12, 2002 at 11:30:28PM +0100, [EMAIL PROTECTED] wrote:
> > > > And why it tries to get 100% CPU even
[EMAIL PROTECTED] 12.11.02 11:24
Once upon a time no realname shaped the electrons to say...
>On Mon, 11 Nov 2002, I've been saying:
>> But why does it only happen with rsync ?
>Ok, the last tests with rsync/rsh have shown the following:
>(all on the receiving side)
>CPU: 100%
>Load: 2.5
>bloc
On Wed, 13 Nov 2002 [EMAIL PROTECTED] wrote:
> I agree, rsh as root is bad. I wouldn't suggest that. I'm talking about
> running "rsync --daemon", using /etc/rsyncd.conf to control the form of
> the access. It's pretty good for reading, and mostly works for writing.
Do I get you right ? You do
AIM
"There are some who call me Tim?"
[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
11/11/02 01:45 PM
Please respond to uwp
To: Tim Conway/LMT/SC/PHILIPS@AMEC
cc: [EMAIL PROTECTED]
Subject:Re: Speed problem
Classification:
On Mon, 11 Nov
On Wed, Nov 13, 2002 at 10:02:34AM +0100, [EMAIL PROTECTED] wrote:
> On Tue, 12 Nov 2002, Wayne Davison wrote:
>
> > On Tue, Nov 12, 2002 at 11:30:28PM +0100, [EMAIL PROTECTED] wrote:
> > > And why it tries to get 100% CPU even though there's nothing to do ?
> >
> > What do you mean "nothing to do
On Tue, 12 Nov 2002, Wayne Davison wrote:
> On Tue, Nov 12, 2002 at 11:30:28PM +0100, [EMAIL PROTECTED] wrote:
> > And why it tries to get 100% CPU even though there's nothing to do ?
>
> What do you mean "nothing to do"? Rsync is creating the new version of
> a changed file which is done both by
On Tue, Nov 12, 2002 at 11:30:28PM +0100, [EMAIL PROTECTED] wrote:
> And why it tries to get 100% CPU even though there's nothing to do ?
What do you mean "nothing to do"? Rsync is creating the new version of
a changed file which is done both by transferring data over the network
and by copying m
On Tue, 12 Nov 2002, Wayne Davison wrote:
> On Tue, Nov 12, 2002 at 04:32:31PM +0100, [EMAIL PROTECTED] wrote:
> > I'd call it a bug.
>
> No, it's not a bug. It's the heart of the rsync algorithm at work.
Hm...
> Rsync trades CPU and local file I/O for network I/O in order to reduce
> the amoun
On Tue, Nov 12, 2002 at 10:03:06AM -0800, Wayne Davison wrote:
> The only alternative is to use the --whole-file option -- this option
> turns off the rsync algorithm and just sends all the changed files over
> the net completely (like an scp copy, but for changed files). This
> should only be use
On Tue, Nov 12, 2002 at 04:32:31PM +0100, [EMAIL PROTECTED] wrote:
> I'd call it a bug.
No, it's not a bug. It's the heart of the rsync algorithm at work.
Rsync trades CPU and local file I/O for network I/O in order to reduce
the amount of data that is transferred over the network. Your diagnosi
Heya !
It seems that we found it out. It's the partial flag. We tested a lot of stuff
here with strace and could see that after some while there came timeouts
on some descriptors (0 = stdin). We saw that after those timeouts got
heavy the blocks-in-out dropped heavily. But the reason wasn't clear
Ok, now I found something. When the effect of heavy speed drop occurs,
it doesn't seem to send much bytes anymore. Block-in rate on the receiving
side drops dramatically from 31000/s to 5000/every 4-8 seconds (which
results to a rate of nearly 1 MB/s, that's what I got in the end).
CPU load goes d
On Mon, 11 Nov 2002, I've been saying:
> But why does it only happen with rsync ?
Ok, the last tests with rsync/rsh have shown the following:
(all on the receiving side)
CPU: 100%
Load: 2.5
blocks in: 38000/s
even though nothing get written
(no statistics)
when it starts to write, it goes from 1
On Tue, Nov 12, 2002 at 07:27:12AM +0100, [EMAIL PROTECTED] wrote:
> On Mon, 11 Nov 2002, jw schultz wrote:
>
> > What is the CPU load of rsync on the receiver? That is
> > important.
>
> I'll check that.
>
> >> The disks have an upper limit of 52 MB/s (ext2) respectively
> >> 45 MB/s (ext3). I
On Mon, 11 Nov 2002, jw schultz wrote:
> What is the CPU load of rsync on the receiver? That is
> important.
I'll check that.
>> The disks have an upper limit of 52 MB/s (ext2) respectively
>> 45 MB/s (ext3). It's an IDE RAID with 12 WD disks.
>
> You are giving us dribs and drabs. Now you men
On Mon, 11 Nov 2002, Craig Barratt wrote:
> > > > You haven't really provided enough data to even guess what
> > > > is limiting your performance.
>
> How similar is the directory tree on the target (receiving)
> machine? There are three general possibilities:
>
> - It's empty.
That is the cas
> > > You haven't really provided enough data to even guess what
> > > is limiting your performance.
How similar is the directory tree on the target (receiving)
machine? There are three general possibilities:
- It's empty.
- It's present, and substantially similar to the sending end.
- I
On Tue, Nov 12, 2002 at 01:05:38AM +0100, [EMAIL PROTECTED] wrote:
> On Mon, 11 Nov 2002 jw schultz wrote:
>
> > You haven't really provided enough data to even guess what
> > is limiting your performance.
>
> As I said in the last mail: One limit for sure is ssh.
Yes, I saw that. Some time aft
On Mon, 11 Nov 2002, Paul Faure wrote:
> Try it without ssh.
But ssh have those nice authentication features...
> ssh may be waiting in the random pool for more entropy (randomness).
> When it grabs a lot of random data, it must wait for more "random" things
Are you sure bout that ? I'm throwin
On Mon, 11 Nov 2002 Bruno Ferreira wrote:
> Look for the processor usage in the machines that are transfering the
> files. You'll probably see that one of those machines has about 100%
This doesn't seem to be the worst point. I mean: the machine is not
going down under pressure or something like
On Mon, 11 Nov 2002 jw schultz wrote:
> You haven't really provided enough data to even guess what
> is limiting your performance.
As I said in the last mail: One limit for sure is ssh.
But: with arcfour I'm getting 18 MB/s and that's where
rsync is actually starting. It's just getting down and
d
On Mon, 11 Nov 2002, jw schultz wrote:
> On Mon, Nov 11, 2002 at 04:30:05PM +0100, [EMAIL PROTECTED] wrote:
> > Mermgfurt !
> >
> > I have some problem with syncing two machines which are connected
> > over a Gigabit-connection. I'm trying to use rsync with ssh because of
> > the authorisation mec
On Mon, 11 Nov 2002 [EMAIL PROTECTED] wrote:
> I don't have a system with ssh available to check with (believe it or not,
> it's not approved for our network), but i think the sshd_config or
Unbelievable !
> ssh_config might be able to specify using compression as a default. Is
> ssh on the sen
On Mon, Nov 11, 2002 at 04:30:05PM +0100, [EMAIL PROTECTED] wrote:
> Mermgfurt !
>
> I have some problem with syncing two machines which are connected
> over a Gigabit-connection. I'm trying to use rsync with ssh because of
> the authorisation mechanisms (keys). It starts quite ok with 18 MB/s
> (
I don't have a system with ssh available to check with (believe it or not,
it's not approved for our network), but i think the sshd_config or
ssh_config might be able to specify using compression as a default. Is
ssh on the sending side, perchance, using a lot of CPU? I don't know of
any cpu
At 16:30 11-11-2002 +0100, you wrote:
Mermgfurt !
I have some problem with syncing two machines which are connected
over a Gigabit-connection. I'm trying to use rsync with ssh because of
the authorisation mechanisms (keys). It starts quite ok with 18 MB/s
(this small speed may have something to d
29 matches
Mail list logo
