Newer versions of OpenSSH and OpenSSL support the NX (gzip) accelerator. When transferring large amounts of data over the network using OpenSSH (ssh, scp or sftp), using compression (-C option) and using the hardware accelerator can make a big difference.

In order to use the NX (gzip) Accelerator with OpenSSH, in addition to the fileset zlibNX.rte, at least the following versions of OpenSSH and OpenSSL are required:

• • OpenSSH: 8.1.102.2102 or newer
  • OpenSSL: 1.0.2.2100 or newer

The use of the NX (gzip) Accelerator must then be permitted on both the client side and the server side.

On the server side (sshd), the following options must be set via the configuration file /etc/ssh/sshd_config:

Compression yes
EnableHwCompression yes

Note: The default value for Compression is “yes”!

You can easily check whether these options are set using “sshd -T”:

# sshd -T | grep -i compression
compression yes
enablehwcompression no
# 

If /etc/ssh/sshd_config is changed, the sshd service must be stopped and restarted:

# stopsrc -s sshd
0513-044 The sshd Subsystem was requested to stop.
# startsrc -s sshd
0513-059 The sshd Subsystem has been started. Subsystem PID is 7012608.
# 

On the client side there are several options:

1. 1. Using “-o EnableHwCompression=yes” when calling the command.
   2. Set “EnableHwCompression yes” in ~/.ssh/config.
   3. Set “EnableHwCompression yes” in /etc/ssh/ssh_config.

Hardware acceleration should be used on both sides, client and server!

First, we copy an approx. 1.5 GB test file with software compression:

$ time scp -C -v file1.tar aix12:
Executing: program /usr//bin/ssh host aix12, user (unspecified), command scp -v -t .
OpenSSH_8.1p1, OpenSSL 1.0.2u  20 Dec 2019
debug1: Reading configuration data /home/user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: using libz from /usr/opt/rpm/lib/libz.a(libz.so.1)
…
debug1: Sending command: scp -v -t .
Sending file modes: C0644 1535078400 file1.tar
Sink: C0644 1535078400 file1.tar
file1.tar                                                                             100% 1464MB  17.8MB/s   01:22   
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 1157736604, received 271372 bytes, in 82.6 seconds
Bytes per second: sent 14015292.0, received 3285.2
debug1: Exit status 0
debug1: compress outgoing: raw data 1535920994, compressed 1156169864, factor 0.75
debug1: compress incoming: raw data 121705, compressed 58364, factor 0.48

real    1m23.515s
user    0m25.425s
sys     0m1.063s
$

Line 5 of the output shows that the “normal” libz is used (/usr/opt/rpm/lib/libz.a). The transfer of the file takes approx. 1m24s with software compression and a throughput of approx. 18 MB/s is achieved.

Next, we repeat the test transfer, but activate hardware acceleration on both sides using the NX (gzip) accelerator:

$ time scp -C -v file1.tar aix12:
Executing: program /usr//bin/ssh host aix12, user (unspecified), command scp -v -t .
OpenSSH_8.1p1, OpenSSL 1.0.2u  20 Dec 2019
debug1: Reading configuration data /home/user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: oslevel : 7.2.0.0

debug1: using libzNX from /opt/freeware/ssh/libzNX_c.a(libz.so.1)
…
debug1: Sending command: scp -v -t .
Sending file modes: C0644 1535078400 file1.tar
Sink: C0644 1535078400 file1.tar
file1.tar                                                                             100% 1464MB  80.0MB/s   00:18   
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 1205350716, received 280788 bytes, in 18.4 seconds
Bytes per second: sent 65570992.2, received 15274.8
debug1: Exit status 0
debug1: compress outgoing: raw data 1535921498, compressed 1203806319, factor 0.78
debug1: compress incoming: raw data 123307, compressed 60913, factor 0.49

real    0m18.754s
user    0m4.370s
sys     0m1.944s
$

The transfer of the test file has been reduced from 1m24s to 19s! The throughput has increased from 18 MB/s to 80 MB/s.

But be careful, before you use compression for data transfer, you should first check whether this actually speeds up the transfer! Finally, compressing the data on the source system and decompressing it on the target system also takes time. With a fast network, this effort may not be worth it and transmission without compression is faster. We carried out a test without compression on the two test systems, which run on the same hardware and the data transfer on Virtual Ethernet runs via the hypervisor. With the following result:

$ time scp -v file1.tar aix12:
Executing: program /usr//bin/ssh host aix12, user (unspecified), command scp -v -t .
OpenSSH_8.1p1, OpenSSL 1.0.2u  20 Dec 2019
debug1: Reading configuration data /home/user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
…
debug1: Sending command: scp -v -t .
Sending file modes: C0644 1535078400 file1.tar
Sink: C0644 1535078400 file1.tar
file1.tar                                                                             100% 1464MB 144.6MB/s   00:10   
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 1536194108, received 254512 bytes, in 10.3 seconds
Bytes per second: sent 148609323.7, received 24621.1
debug1: Exit status 0

real    0m10.668s
user    0m2.908s
sys     0m0.604s
$

The transfer now only takes 11s and is therefore almost twice as fast as with hardware compression! Throughput has increased to approximately 145 MB/s. In this case, using compression, even if a hardware accelerator is used, does not make sense!