Hi Daniel.

I've been trying a few more things since trying to increase the buffer size but unfortunately, i'm still no further forward on finding the cause of the problem. This is what i've now tried:
1. Increasing the receive buffer size

2. Running Wireshark to see if I can see anything obvious.
3. Running Traceplus/Winsock and comparing the API calls between libcurl and wfetch for any obvious differences.

If it hadn't been for the fact that IE and wfetch retrieve the file much faster I would have put the blame on my VM.

Is there anything else you can suggest?

Regards,
Kevin.

On Wednesday, 22 January 2014, 18:24, Kev <s7g2vp2_at_yahoo.co.uk> wrote:
Hello Daniel.

I have been experimenting with this today.

1. I added the following test code to the top of Curl_sndbufset():

const int CURL_MAX_READ_SIZE = 32768;

  if(getsockopt(sockfd, SOL_SOCKET, SO_RCVBUF, (char *)&curval, &curlen) == 0)
    if(curval < CURL_MAX_READ_SIZE)
      setsockopt(sockfd, SOL_SOCKET, SO_RCVBUF, (const char *)&CURL_MAX_READ_SIZE, sizeof(CURL_MAX_READ_SIZE));

2. I built the VS project and tested it on my XP VM that runs Visual Studio.
Originally, XP was not an operating system I mentioned as curl was very close to IE (62s vs 55s). However, with this new version the download time dropped to approx. 11 seconds.

so... The receive buffer size definitely has an impact on the speed under XP.

3. I copied the new curl executable to my Windows 7 VM and one of our demo Windows 2008 Server VMs.
Unfortunately, my tests indicate that there is no improvement under these operating systems. I have also tried with 64K and 1MB buffers but neither make any difference.

Regards,
Kevin.

On Wednesday, 22 January 2014, 13:35, Daniel Stenberg <daniel_at_haxx.se> wrote:
On Wed, 22 Jan 2014, Kev wrote:

> However, as a test I added the TcpAckFrequencyRegistry setting to my Windows
> 7 VM that is performing the download (not the server). After a restart the
> file downloaded in approx. 9 seconds which is roughly what I expect. I also
> tested removing the registry setting and then restarting. As expected,
> performance dropped back to what it was previously.

The Windows TCP stack keeps playing this kind of tricks on us and we keep
doing weird tricks trying to strike back. It's a never-ending battle.

Previously we've debated setting SO_RCVBUF on windows to something large to
make it download faster by default but we never settled on anything. Maybe you
can try just setting that to something largish just to see what difference it
can make for you?

A fine place to add it in the code for testing could probably be in the
lib/connect.c:Curl_sndbufset() function...

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html