Hello

I finally received access to slow upload machine config. First of all: the ping value is 57ms (it's even worse than i thought), "netsh interface tcp global" values are the same as described in previous messages.
I made several curl builds: with modified CURL_MAX_WRITE_SIZE (MAX) and modified set SO_SNDBUF routine, and run quick test by upload 70mb.

MAX=524288 SNDBUF=ORIGINAL ROUTINE
sftp:1129k
ftp:5700k

MAX=524288 SNDBUF=DETECTOS (disable adj for post Vista)
sftp:1013k
ftp:5675k

MAX=16384 SNDBUF=8388608
sftp:272k
ftp:4950k

MAX=16384 SNDBUF=4194304
sftp:270k
ftp:6130k

MAX=16384 SNDBUF=2097152
sftp:245k
ftp:6247k

MAX=16384 SNDBUF=524288
sftp:269k
ftp:6681k

MAX=16384 SNDBUF=262144
sftp:242k
ftp:4815k

MAX=16384 SNDBUF=131072
sftp:270k
ftp:2410k

MAX=16384 SNDBUF=65536
sftp:245k
ftp:987k

MAX=16384 SNDBUF=32768
sftp:246k
ftp:604k

MAX=16384 SNDBUF=ORIGINAL ROUTINE
sftp:249k
ftp:549k

MAX=16384 SNDBUF=DETECTOS (disable adj for post Vista)
sftp:250k
ftp:560k

so disabled SO_SNDBUF adjustment did not fix this problem.
may be curl-lib should allow to specify buffer size(with CURLOPT_BUFFERSIZE or similar opt) larger than CURL_MAX_WRITE_SIZE? default value will remain equal to CURL_MAX_WRITE_SIZE(16kb) but command line tool or host app will receive ability to increase that buffer without recompilation.

ps
ignore sftp values

08.02.2013, × 1:10, Daniel Stenberg <daniel_at_haxx.se> ÎÁÐÉÓÁÌ(Á):

> On Wed, 6 Feb 2013, Kurushin Andrey wrote:
>
>> 1. the main bug report (filezilla vs far manager vs curl) contains test of cross-countries test results (ping >8ms). recent tests (with custom builds of 7.28.1) were made inside single subnet (ping < 1ms) so they have better speed values.
>
> Well, 8 vs 1 ms latency shouldn't make much of a difference to a fairly large plain FTP transfer.
>
>> 2. CURL_MAX_WRITE_SIZE = 16kb and SO_SNDBUF=8mb gives very good ftp upload speed (equal to version with big global buffer)
>
> Interesting! So have you tried with for example 4mb, 2mb or 512kb etc to see if there's a particular cut-off limit somewhere?
>
> It is a bit weird that the TCP stack can't sort this out by itself...
>
>> but sftp upload speed still have 6Mb/s limit.
>
> Yes, but I've explained several times on this list and on the libssh2 list, the reason for SFTP's problems is _entirely_ different and in fact just growing the buffer size is only one piece of the fix to the SFTP performance bottleneck we can see.
>
> If you really want to address the SFTP problem then I won't mind helping out, but we cannot mix the two problems into one and pretending that they are the same.
>
>> So the best way to increase both ftp and sftp upload speed is to increase CURL_MAX_WRITE_SIZE;
>
> Possibly. But we can't unconditionally just bump the 16K up to something crazy like 512K. We have applications who do hundreds of even thousands of parallel transfers, they will not appreciate such a massive memory bloat.
>
> Possibly the time has come to start working on allowing a custom size for the buffer.
>
> --
>
> / daniel.haxx.se
> -------------------------------------------------------------------
> List admin: http://cool.haxx.se/list/listinfo/curl-library
> Etiquette: http://curl.haxx.se/mail/etiquette.html

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-02-08