sftp performance problem, cured by TCP_NODELAY

[Tony Finch]

Miklos Szeredi <miklos at szeredi.hu> wrote:
>> In broad handwaving terms, applications that try to do "write write
>> read" can run afoul of interactions between Nagle and delayed ACK.
>
>Which is exactly what sftp does.
>
>Excerpt from sftp(1):
>
>|      -R num_requests
>|              Specify how many requests may be outstanding at any one time.
>|              Increasing this may slightly improve file transfer speed but
>|              will increase memory usage.  The default is 16 outstanding
>|              requests.
>
>I also noticed, that -R 1 actually increases throughput in some cases,
>which is nicely explained by the fact, that then it will always be
>"write read" pairs.
>
>Of course -R 1 will still result in suboptimal throughput, so that is
>not the solution.

Actually this part of the SFTP protocol is disastrous for links with large
bandwith * delay products, and it's pointless given that the underlying
TCP connection is already doing windowing. SFTP should just send data
as fast as it can.

http://www.cs.auckland.ac.nz/~pgut001/pubs/app_sec.pdf

Tony.
-- 
f.a.n.finch  <dot at dotat.at>  http://dotat.at/
BISCAY: EAST 4 OR 5 BECOMING VARIABLE 3 OR 4. MAINLY FAIR. MODERATE OR GOOD.