Dan Fandrich wrote:
> On Fri, Oct 12, 2007 at 06:35:43PM +0200, Alessandro Vesely wrote:
>> Yup, after setting line 224 in curl.h to
>> #define CURL_MAX_WRITE_SIZE /* 16384 */ (16*1460)
>> I obtained "7" once and the packets' size stays steady. (I must have some
>> problems on the hub, since I captured 5540 packets --16 more than needed.)
>
> But does it affect the overall transfer rate?
>

Yes, it does: "7" is 8058822B/7sec = 1124K/sec, the best timing for
an ftp transfer of that file I've been able to obtain. Normally,
curl takes 8 seconds to do that transfer (seconds rounded upward.)

That only works as 1460 is the max segment size for an MTU of 1514
(including 14 bytes of ethernet header) and no IP options. Doing it
programmatically implies learning the MTU value on the relevant path,
and perhaps looks rather a hack than proper programming practice.

This is not a windoze-specific topic, as I've transferred the same
file from a current debian system to the same server, using the
installed curl (7.15.5) as well as the local ftp command line tool.
Curl still takes a few fractions of a second more. It still sends a
small "odd" packet after each 11th full one. In addition, curl's mss
drops to 1448 because of the tstamp option. Debian's command line ftp
tool also sends some spare small packets, but only 8 out of 5530; and
it manages to get a 1460 mss.
Received on 2007-10-13