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 do with our internal net)
and falls
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
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
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
(this
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
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 mechanisms
I have added regular expression support using a POSIX implementation.
The patch (against 2.5.5) is attached.
The implementation is simple and follows the same mechanism that is
implemented for normal searches.
I added these command line arguments:
--rexclude=PATTERN exclude files matching
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
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, 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 throwing a
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 after i
The weak checksum in checksum.c (see snippet below) differs
substantially from the one discussed in Andrew Tridgell's doctoral
thesis on rsync and elsewhere that I've been able to find. I didn't
find discussion of the change in the mailing list archives. Well, so
I'm curious what the benefit of
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.
- It's
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 case at the
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 mention
15 matches
Mail list logo
