On 2020-09-08 15:06:31 [+0200], Steffen Nurpmeso wrote: > Sebastian Andrzej Siewior wrote in > <20200908073415.ymmao6fcemn5hqns@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. > --steffen Sebastian _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
