On Wed 2019-06-26 08:04:44 +1000, Darren Tucker wrote:
> On Wed, 26 Jun 2019 at 02:50, JCA <1.41421@xxxxxxxxx> wrote:
>> Thanks; I did not think of that. I have just run a few basic tests with
>> both rsync and OpenSSH in their default settings, when it comes to
>> compression. SSH compression seems to have a very slight edge.
>
> OpenSSH does not allow you to set the zlib compression level for SSH2
> (the protocol spec does not have a mechanism for doing so, although
> it'd be possible to add it as a non-standard hack) and OpenSSH
> hardcodes it to 6. In rsync you can crank it up to --compress-level=9
> which I'd expect to make it beat any theoretical advantage SSH might
> have on compressible data, plus it can be smarter about skipping
> already-compressed file types.
I note that the original question mentioned a concern about a "waste of
resources and time" -- this discussion seems to assume that bandwidth is
the only expensive or latency-inducing resource.
But of course compression and decompression can be expensive and
latency-inducing in terms of CPU and RAM (especially at the more extreme
ends of the compression dial), even if you might save on bandwidth.
This is going to really depend on which resources are more valuable to
you in a given context.
--dkg
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
