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 <[email protected]> написал(а):

> 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

Reply via email to