This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: socket performance (was Re: Building cygwin1.dll)

If your running Windows 7 or 2k8 are you running the following hotfix, if not
you should try that too, just in case you machine has got a degraded tcp


----- Original Message ----- From: "Corinna Vinschen"
Sent: Tuesday, January 10, 2012 2:45 PM
Subject: Re: socket performance (was Re: Building cygwin1.dll)

On Jan 10 14:45, Johan van den Berg wrote:

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?

What Windows versions are we talking about? Is that pre-Vista? XP, for instance? If so, setting the buffer size > 64K should have no effect.

I really don't know why the performance should be so much worse than
under Linux in your scenario, sorry.  Cygwin is not trying to do
anything fancy.  The speed should be basically in the same range as on

At least it is for me when using sftp.  When using scp I just found that
I get a similar bad performance, only 6.9 MB/s instead of 35 MB/s.

Is it possible that the limiting factor is not the socket, but the pipes
between rsync and ssh, assuming you are using rsync over ssh?


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Problem reports:
Unsubscribe info:

-- Problem reports: FAQ: Documentation: Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]