Re: Why SFTP performance sucks, and how to fix it

[pgut001%cs.auckland.ac.nz@localhost (Peter Gutmann)]

Markus Friedl <markus%openbsd.org@localhost> writes:

>when multiplexing multiple ssh channels over one connection and one of the
>consumers is very slow, then the tcp flow control will not help. AFAIK, this
>is one of the reasons why there's an additional per-channel flowcontrol.

Ahh, that makes sense.  Thanks.  Still, it just shows that there are different
situations where the Ack-based flow control is appropriate, since the converse
says that when not muxing multiple channels, TCP flow control should do.
Specifically, if I'm using SFTP as just a secure FTP (without anything fancy
like SSH port forwarding, just a dumb copy), it's just an updated form of
rcp/scp: Open a connection, blast data across as quickly as possible, close
the connection, either with a successful close or an unsuccessful disconnect
on error, just as rcp does.  All I want at that point is the fastest possible
transfer, if there's a flow-control problem TCP flow control will handle it,
and if there's a fatal error then all you can do is close the session, just
like standard rcp.

Since it's situation-specific, software could either enable it when there's no
need for Ack-based flow control (e.g. the example I gave above), or when
requested by users.  As a command-line option, I think -u (for "ludicrous
speed") would be the only viable candiate (-l is taken, and so is -p for
"plaid").

Peter.