On 09 Jan 2012, at 3:43 PM, Corinna Vinschen wrote: > How's the performance in your scenario when applying the below patch > instead of yours?
I have to run back with my tails between my legs. I implemented your patch, and the transfer speed on a 200ms latency, 10mbit max link went down to 5-6mbit using rsync. I then rolled back to my version, and suddenly also got 5-6mbit. I started another rsync and I was able to max the 10mbit line, hence, I think my original patch never had the effect I hoped for. Checking further, I noticed that stopping a task in windows task scheduler doesn't actually stop the rsync, so the only reason why I then must have seen that 10mbit max on my patch was simply because another rsync was already running ;( I am now however back to the drawing board. With your patch on both ends of the line, with a client rsync option of "--sockopts=SO_SNDBUF=2000000,SO_RCVBUF=2000000" I still only get 5-6mbit max. I installed iperf on both ends, and no combination of settings (higher window size, higher MSS) will give me more than 5-6mbit transfer rate, except when I add the -P option which does parallel transfers. As soon as I do parallel, I can max the line. I then tested with a 100mbit link, and got similar results. Thinking outside the box, I started up iperf on a linux box on the other end of a 100mbit line: Cygwin to cygwin = 5mbit Cygwin to linux = 5mbit Linux to linux = 28mbit In all cases, adjusting the window size had no effect other than making the client "think" it can transfer faster if the buffer is bigger than the total amount of data to send. Any advice while I carry on trying to figure this out? Kind regards Johan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
