Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Message-ID:	<005801c46ad4$e485ee10$b3db87d4@multiplay.co.uk>
From:	"Steven Hartland" <killing AT multiplay DOT co DOT uk>
To:	<alexis AT alexisgallagher DOT com>, <cygwin AT cygwin DOT com>
Cc:	<rurban AT x-ray DOT at>
References:	<40F70F79 DOT 9030306 AT alexisgallagher DOT com>
Subject:	Re: rsync very slow, but not a network issue
Date:	Fri, 16 Jul 2004 02:33:25 +0100
MIME-Version:	1.0
X-Spam-Processed:	multiplay.co.uk, Fri, 16 Jul 2004 02:29:52 +0100 (not processed: message from valid local sender)
X-MDRemoteIP:	212.135.219.179
X-Return-Path:	killing AT multiplay DOT co DOT uk
X-MDaemon-Deliver-To:	cygwin AT cygwin DOT com
X-MDAV-Processed:	multiplay.co.uk, Fri, 16 Jul 2004 02:29:53 +0100
X-IsSubscribed:	yes

----- Original Message ----- 
From: "Alexis Gallagher" 

I've repeated your tests with a P4 2.4Ghz windows XP using SFU
and a PIII 800Mhz running FreeBSD 5.1


> %[local copy, target file is different ]
> %time rsync test1.mp3 test2.mp3
> 
> real 0m6.422s
> user 0m0.430s
> sys  0m1.431s

P4: time rsync test1.mp3 test2.mp3
real    0m1.906s
user    0m0.344s
sys     0m0.343s
P3:time rsync test1.mp3 test2.mp3
real    0.380u 
user   0.233s 
sys    0:00.81

> %[local copy, target file is the same ]
> %time rsync test1.mp3 test1-same.mp3
> 
> real 0m6.523s
> user 0m0.300s
> sys  0m1.261s

P4(SFU): time rsync test1.mp3 test2.mp3
real    0m0.906s
user    0m0.500s
sys     0m0.157s

P4(cygwin): time rsync test1.mp3 test2.mp3
real    0m26.005s
user    0m1.060s
sys     0m3.732s

P3:time rsync test1.mp3 test2.mp3
real    0.326u 
user   0.264s
user   0:00.72

> %cp test2.bak test2.mp3
> %[network copy, a pure copy with scp for benchmark]
> %time scp test2.mp3 $TEST:
> 
> 260.6KB/s (calculated average)
> real 0m16.257s
> user 0m0.510s
> sys  0m1.091s

P4(SFU)->P3:
4.5MB/s
real    0m3.188s
user    0m1.312s
sys     0m0.438s
P4(cygwin)->P3:
2.6MB/s
real    0m4.433s
user    0m0.639s
sys     0m0.561s

P3->P4
5.3MB/s:
real   1.356u 
user   0.439s 
sys    0:05.38

[network copy, ftp]
P3 -> P4
10.85 MB/s
P4(windows)->P3
10.85 MB/s
P4(cygwin)->P3
9.43 MB/s

> %[network copy, target file is different ]
> %time rsync test1.mp3 $TEST:test2.mp3
> 
> real 0m13.797s
> user 0m1.421s
> sys  0m1.250s

P3->P4
real 3.652u
user 0.411s
sys  0:05.39
P4(SFU)->P3
real    0m4.516s
user    0m1.968s
sys     0m1.093s
P4(cygwin)->P3
real    0m7.722s
user    0m1.357s
sys     0m1.030s

> 
> % (network copy, files are 100% the same)
> % (repeated twice to guarantee target file is there)
> %time rsync test2.mp3 $TEST:test2.bak
> 
> real 0m28.329s
> user 0m1.390s
> sys  0m4.766s
> 

P4: rsync --version
rsync  version 2.6.0  protocol version 27
OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7c 30 Sep 2003
P3: rsync --version
rsync  version 2.6.0  protocol version 27
OpenSSH_3.6.1p1 FreeBSD-20030423, SSH protocols 1.5/2.0, OpenSSL 0x0090701f

> %rsync --version
> rsync version 2.6.2 protocol version 28
> ssh $TEST rsync --version
> rsync version 2.6.2 protocol version 28
> $ ssh -V
> OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004
> $ ssh $TEST ssh -V
> OpenSSH_3.7.1p1, SSH protocols 1.5/2.0, Open SSL 0.9.7d 17 Mar 2004
> (but ssh -v reports TEST's sshd server is responding with
> OpenSSH_3.6.1p1+CAN-2003-0693, SSH protocols 1.5/2.0, Open SSL 0x0090702f )
> $ uname -r
> 1.5.10(0.116/4/2)

Result is although the copy is cpu limited in ssh and cygwin ssh is slower
than SFU ssh it doesn't explain the same file test results:
SFU: real    0m0.906s
Cygwin: real    0m26.005s

Strange behaviour noticed. It appears that for each block tested cygwin
is opening a new connection instead of using the current one this could
well be where the performance is being lost as this doesn't happen
under SFU.

    Steve


================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137
or return the E.mail to postmaster AT multiplay DOT co DOT uk.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -