Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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: <40F3C6CE.6030602@alexisgallagher.com> Date: Tue, 13 Jul 2004 12:26:06 +0100 From: Alexis Gallagher Reply-To: alexis AT alexisgallagher DOT com User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) MIME-Version: 1.0 To: Steven Hartland CC: cygwin AT cygwin DOT com Subject: Re: rsync very slow, but not a network issue References: <40F3BFC4 DOT 9060000 AT alexisgallagher DOT com> <009b01c468ca$217959e0$b3db87d4 AT multiplay DOT co DOT uk> In-Reply-To: <009b01c468ca$217959e0$b3db87d4@multiplay.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Steve, Steven Hartland wrote: > Is this not because its showing you the network transfer rate i.e. spending > all its time doing compression and therefore not having to do actual > network transfers? How long did each test take? > I just performed the test again, this time timing the transfers with a stopwatch. (This time I was transferring a text file that consisted of 5 million zeros, which is about 5MB.) Here's what I found. scp: 19 seconds rsync (no there): 17 seconds rsync (already there): 93 seconds So it's taking much longer in real time when the file is already there, which is exactly the situation where rsync is supposed to accelerate teh transfer. The cygwin machine is a Pentium III 1Ghz, and the eMac is a bit faster I believe. This should be fast enough that it's not bottlenecking on the hash computation, I think. Cheers, Alexis -- 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/