On Thu, 27 May 2010, Candid Shot wrote:

> Cygwin version is able to send data faster. This is confirmed by the
> presence of back-to-backk jumbo frames of 16KB each, as it is also the
> maximum read size in libcurl, reaching upto 65KB -- the maximum windows of
> TCP.

64KB is the traditional maximum TCP window limit, which was extended by
RFC1323 so it can now be (much) larger.

> In Cygwin, these back to back frames would later follow an ack from the
> other side (i.e. server). Whereas with windows compilation, the jumbo frames
> rarely stack up. I will never see 4 16KB packets going out back to back,
> even though the TCP window is wide open then!

I find that VERY curious. The libcurl code is virtually identical for cygwin
and standard windows builds so the differences you see almost have to be due
to magic done outside of libcurl's control and I find it surprising that
cygwin would handle that better than the "native" socket API!

An interesting experiment could possibly to try to alter the buffer size that
libcurl uses to see if it makes any difference.

> I also ran a python program over the same file in Cygwin, and that also
> confirmed the back to back jumbo frames going out.

This then pretty much confirms that issue isn't actually a libcurl problem,
doesn't it?

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html