This is a discussion on Optimizing SFTP for high latency connection - SSH ; Dear all, I was recently testing data transmission on an emulated WAN link using the SFTP feature that comes with WinSCP3. I set the latency to 100ms, and observed a channel utilitization of 2.4Mbps out of 200Mbps available bandwidth. CPU ...
I was recently testing data transmission on an emulated WAN
link using the SFTP feature that comes with WinSCP3. I set
the latency to 100ms, and observed a channel utilitization
of 2.4Mbps out of 200Mbps available bandwidth. CPU load on
both ends are low, less than 5%. I speculated that WinSCP3
imposed a limit on data transmission.
The first thing I did was to change the TCPWindowSize to a
higher value, restarted the computer, and hoped it sped up.
However, this did not work, which convinced me that the
2.4Mbps limit is related to a prespecified configuration in
the software itself.
Fortunately, WinSCP3 is an open source software so I could
download the source code. From my brief examination of the
code, I gathered that WinSCP3 uses PuTTy to provide the SSH
connection to the other end, so I examined the PuTTY ssh.c
code in more detail. In this file I found a variable called
which seems to be limiting the amount of data coming in and
going out, which I guess is related to the rekeying feature
in PuTTy. Where can I find the default parameter value for
max_data_size? From the code I can see it's parsed from the
ssh_rekey_data in the configuration structure, but I could
not find where this was initialized (was it from the front-
end / user interface)?
To understand more about SFTP, I read the protocol I found
from IETF's website, which says in section 11:
11. Implementation Considerations
The data size of requests should match the maximum packet
size for the next layer up in the protocol chain. When im-
plemented over ssh, the best performance should be achieved
when the data size matches the channel's max packet and the
channel window is a multiple of the channel packet size.
Is max_data_size the "maximum packet size" or the "channel
packet size" referred to in the protocol document? To get a
better performance, I set the TCPWindowSize parameter to a
large value, but this seems not to have any effect on the
transmission. Is it because the channel packet size (if it
is indeed max_data_size) is too small?
Sorry for the long email. Thanks in advance.