4 ms·

Because (afaik), the single-threaded ssh program is the bottle-neck.

nurettin 7mo ago
It is a bottleneck for multiple files, but will it speed up with a single file?This is how we sent files for decades. Archive, transfer, unarchive. So I'm wondering what the point is.
- i_think_so 7mo ago
  It depends on the size of the file, of course. For copying your 90 line .bashrc, probably not noticeable in the noise. For copying an 800GB database? Um, yeah. :-) I see this project's main value in turning loose the power of multiple cores on a filesystem full of manifold directories, backed by flash based storage that only runs optimally at queue depth >1 (which is most of them). On spinning rust this will probably just thrash the heads. Hmmm. I wonder how 2 or 3 threads perform with zfs and a reasonable sized ARC?
  - nurettin 7mo ago
    800gb database is still a single file, if it only threads on file level, you shouldn't see a difference.
    - i_think_so 7mo ago
      We definitely need more information. 9 or 10 years ago, under Solaris/Sparc with 1000BaseT connections, things were quite different than even the most boring and average Linux environment today. This discussion should drive home the importance of not listening to conventional wisdom and presuming optimal performance without actually testing your options. And particularly, don't presume that a blog post (or an LLM that scraped it) knows what's right for your particular use case.
i_think_so 7mo ago
It used to be possible in openssh to use -c none and skip the overhead of encryption for the transport (while retaining the protection of rsa keys for authentication). Even the deprecated blowfish-cbc was often faster than aes-ni for bulk transfers. I remember cutting off hours of wait time in backup jobs using these options. Sadly it appears those days are gone now. 3des is still supported, probably for some governmental environments, but it was always a slower algorithm. Unless there are undocumented hacks I think we're stuck with using proper crypto. Oh darn.
- mmh0000 7mo ago
  `-c none` hasn't worked in SSH for at least a decade. The `none` option was for SSHv1 which was already quite old when it was fully removed from OpenSSH 7.6 in 2017[1]. https://www.openssh.com/releasenotes.html https://www.openssh.com/releasenotes.html
  - i_think_so 7mo ago
    Now that you mention it, I think that probably was around the the last time I used it. Time flies.
- adrian_b 7mo ago
  If blowfish was faster than AES, then it is certain that either the CPU did not support the AES instructions (AES NI = AES New Instructions), or the ssh program, either at the client or at the server was compiled without AES instructions support. Blowfish is many times slower than AES on any CPU with AES instructions. Old CPUs with AES support needed around 1 clock cycle per byte, but many modern CPUs need only around 0.5 clock cycles per byte and some CPUs are even twice faster than this. 0.5 clock cycles per byte means a 10 GB/s = 80 Gb/s encryption throughput per core @ 5 GHz, so only for 100 Gb/s or faster Ethernet you might need to distribute encryption on multiple cores to reach full network link throughput. For full AES speed, one must not use obsolete modes of operation like CBC or obsolete authentication methods like HMAC. For maximum speed, one must use either aes128-gcm@openssh.com or aes128-ctr + umac-64@openssh.com. For increased security at lower speed, one can use aes256-gcm@openssh.com or aes192-ctr or aes256-ctr with umac-128@openssh.com. In general, one should never use the default configuration of ssh for cipher and MAC algorithms, but one should delete all obsolete algorithms and allow only the few without problems, unless one has to make connections to legacy systems.

It is a bottleneck for multiple files, but will it speed up with a single file?This is how we sent files for decades. Archive, transfer, unarchive. So I'm wondering what the point is.

i_think_so 7mo ago
It depends on the size of the file, of course. For copying your 90 line .bashrc, probably not noticeable in the noise. For copying an 800GB database? Um, yeah. :-) I see this project's main value in turning loose the power of multiple cores on a filesystem full of manifold directories, backed by flash based storage that only runs optimally at queue depth >1 (which is most of them). On spinning rust this will probably just thrash the heads. Hmmm. I wonder how 2 or 3 threads perform with zfs and a reasonable sized ARC?
- nurettin 7mo ago
  800gb database is still a single file, if it only threads on file level, you shouldn't see a difference.
  - i_think_so 7mo ago
    We definitely need more information. 9 or 10 years ago, under Solaris/Sparc with 1000BaseT connections, things were quite different than even the most boring and average Linux environment today. This discussion should drive home the importance of not listening to conventional wisdom and presuming optimal performance without actually testing your options. And particularly, don't presume that a blog post (or an LLM that scraped it) knows what's right for your particular use case.

i_think_so 7mo ago

It used to be possible in openssh to use -c none and skip the overhead of encryption for the transport (while retaining the protection of rsa keys for authentication). Even the deprecated blowfish-cbc was often faster than aes-ni for bulk transfers. I remember cutting off hours of wait time in backup jobs using these options. Sadly it appears those days are gone now. 3des is still supported, probably for some governmental environments, but it was always a slower algorithm. Unless there are undocumented hacks I think we're stuck with using proper crypto. Oh darn.

mmh0000 7mo ago
`-c none` hasn't worked in SSH for at least a decade. The `none` option was for SSHv1 which was already quite old when it was fully removed from OpenSSH 7.6 in 2017[1]. https://www.openssh.com/releasenotes.html https://www.openssh.com/releasenotes.html
- i_think_so 7mo ago
  Now that you mention it, I think that probably was around the the last time I used it. Time flies.
adrian_b 7mo ago
If blowfish was faster than AES, then it is certain that either the CPU did not support the AES instructions (AES NI = AES New Instructions), or the ssh program, either at the client or at the server was compiled without AES instructions support. Blowfish is many times slower than AES on any CPU with AES instructions. Old CPUs with AES support needed around 1 clock cycle per byte, but many modern CPUs need only around 0.5 clock cycles per byte and some CPUs are even twice faster than this. 0.5 clock cycles per byte means a 10 GB/s = 80 Gb/s encryption throughput per core @ 5 GHz, so only for 100 Gb/s or faster Ethernet you might need to distribute encryption on multiple cores to reach full network link throughput. For full AES speed, one must not use obsolete modes of operation like CBC or obsolete authentication methods like HMAC. For maximum speed, one must use either aes128-gcm@openssh.com or aes128-ctr + umac-64@openssh.com. For increased security at lower speed, one can use aes256-gcm@openssh.com or aes192-ctr or aes256-ctr with umac-128@openssh.com. In general, one should never use the default configuration of ssh for cipher and MAC algorithms, but one should delete all obsolete algorithms and allow only the few without problems, unless one has to make connections to legacy systems.