Compression is desirable on modem lines and other slow connections, but will only slow down things on fast networks. The compression algorithm is the same used by gzip(1), and the “level” can be controlled by the CompressionLevel option for protocol version 1. C Requests compression of all data (including stdin, stdout, stderr, and data for forwarded X11, TCP and UNIX-domain connections). C Enables compression (via ssh's -C flag). You could try and enable compression, and see if that helps. So, try to compile and use HPN-SSH on the receiving side, and see whether it improves your transfer speed. In addition HPN clients will be able to download faster from non HPN servers, and HPN servers will be able to receive uploads faster from non HPN clients.
#Better sftp for mac Patch
We have created a patch that will remove the bottlenecks in OpenSSH and is fully interoperable with other servers and clients.
#Better sftp for mac code
Modifying the ssh code to allow the buffers to be defined at run time eliminates this bottleneck. These buffers often end up acting as a bottleneck for network throughput of SCP, especially on long and high bandwith network links. SCP and the underlying SSH2 protocol implementation in OpenSSH is network performance limited by statically defined internal flow control buffers.
There's a patch to OpenSSH that explicitly improve throughput on a high-latency network link: HPN-SSH: (emphasis mine) Have you measured the actual latency, and what are the results?) (You mention "high latency" in the question title, but not in the body text.
0 kommentar(er)
