[PATCH 0/5] ZSTD compression support for OpenSSH
Steffen Nurpmeso
steffen at sdaoden.eu
Wed Sep 9 07:43:34 AEST 2020
Sebastian Andrzej Siewior wrote in
<20200908195245.gs5ve6fsvbyseuhx at flow>:
|On 2020-09-08 15:06:31 [+0200], Steffen Nurpmeso wrote:
|> Sebastian Andrzej Siewior wrote in
|> <20200908073415.ymmao6fcemn5hqns at flow>:
|>|A key stroke is here 10 bytes of raw data which zstd compresses usually
|>|into 10 bytes while zlib manages to squeeze it into 5 bytes. This leads
|>|to better compression ratio for zlib in ssh's accounting (visible in
|>|verbose mode after connection terminates). The data length, that will be
|>|transferred over the wire, is the same for 5 and 10 bytes data after the
|>|crypto part (with padding and so on).
|>
|> Then something must be wrong on the configuration side for sure.
|> I personally have switched all possible private use cases to zstd
|> years ago, in can be configured to be tremendously fast, faster
|> even than lz4, no?, or compress almost as good as xz, it depends
|> on the data, xz can surely outperform it in size.
|> On the decompression side zstd is just tremendously fast.
|> And all in one algorithm.
|
|I don't follow. A key stroke is one ssh packet which has 10 bytes.
|This packet must be compressed in a way that it can be fully
|decompressed once received on the remote side (ZSTD_e_flush in zstd
|terms which finishes the current block). Due to the way framing works in
|zstd we end up with a 10 bytes block. Higher compression levels can
|achieve 9 bytes but as I stated it does not make sense due to padding of
|the compressed data. The zlib framing is smaller here but then zstd
|knows exactly how many bytes it will decompress and when the block/frame
|ends.
|
|Do note that this is not simple file compression where you end up with
|one frame and blocks created on demand.
I see. Thanks for the explanation.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
More information about the openssh-unix-dev
mailing list