Most of us are well versed in SSH, used for general terminal access, port forwarding, inter-computer communication and more. SSH supports compression, but the man page has had this line in it as long as I can recall (at least 20 years):
Compression is desirable on modem lines and other slow connections, but will only slow down things on
fast networks.
I wondered if that was still true. When I first remember seeing this my machine was a 32 bit, maybe 400Mhz single core computer, with memory measured in megs and not gigs, but even back then networking was commonly 100Mbit (10Mbit was still around, but fading out). I think it made quite good sense then.
Recently as part of my flipClock project, I was using SSH to forward X11 windows to my mac for Arduino programming. I noted as part of my Pine64 review that this seemed enormously faster on the Pine64. Which makes sense because the Pine64 has a 1Gbit ethernet port, that is directly tied into the chipset. The RaspberryPi line uses a 100Mbit ethernet port which is actually a USB ethernet adapter chip soldered on the main board. This leads to additional lag and performance loss, normally not an issue, as no one is using a RaspberryPi as a power house network computer….but it did get me to wondering if the compression option could help us out, as the RaspberryPi 2 B that I was using did have 4 cores, and surely one them could be used for compression and help out the link. I ran SSH -CYX RaspberryPiIPAddress and noticed a subjective improvement. So I decided to do some tests.
Test Setup:
- Machine A: Raspberry Pi model 2 B, no over clocking
- Machine B: iMac 3.5GHz intel i5
- Hooked thru a netgear gigabit switch directly
First Test: Text to console
In this test I made a simple bash script to cat a syslog 100 times. I figure this is a fair representation of the average kind of text you might expect over a linux terminal. I used the time command on the pi for the total time. After several tests the averages were:
- SSH with no compression: 2.77 seconds
- SSH with compressionLevel 9: ~4.3 seconds – much slower
- SSH with compressionLevel 1 : ~4 seconds ~ much slower
So it seems the man page is still correct! But what about my subjective xterm improvement time? I logged in with an xterm to run the same test, now X11 would be sending the text as graphics (* sort of, X11 is beyond the scope of this post).
- SSH with no compression : 19 seconds
- SSH with compressionLevel 9: 19 seconds
- SSH with compressionLevel 1: 19 seconds
How does this jive with my experience? I wondered if it was the amount of space, or something similar. It dawned on me that an xterm showing text would have the entire xterm changing all the time. What if I made the window larger? such that it had many columns of white space on the end of most lines, like a arduino window. So I made the window roughly 200 characters wide x 130 tall, even this takes up less than half my iMac screen
Big Window:
- SSH no compression: 2m34s
- SSH with compression Level 9: 26 seconds!
- SSH with compression Level 1: 24 seconds!
A Huge difference! 2 and half minutes down to 24 seconds. With compression this task took 16% of the time of no compression!
So it would seem that SSH compression makes sense on a local network in some specific instances. Namely X11 windows with a lot of easy to compress similar space in the windows. If you know a little about compression, you know that it takes common patterns and represents them with a token. For more info you can google some compression algorithms. “Deflate” is a common one
How about on a Pine64? A gigabit ethernet port, and slightly faster 64 bit machine?
Small x-window:
- SSH no compression: 18.1 seconds
- SSH compression level 1 : 18.2 seconds
The small x-window is really within the margin of testing.
Big window:
- SSH no compression: 28 seconds
- SSH compression level 1: 19 seconds
An improvement on the big window over uncompressed. but this time instead of 16% of the time it took 68% of the time. Still a noticeable improvement, but not nearly the same as on the 100M link.
Text only (to be fair with the above) :
- SSH no compression 2.7 seconds
- SSH compression level 1 : 2.49 seconds
- SSH compression level 9 : 2.49 seconds
This was little bit of surprise, as I expected not so much difference at all. So it took 92% of the time with compression. I wonder if this is due to some faster 64bit ssh implementation?
So here we can see even on a fast 1Gbit pipe, compression still helps on big x-windows. I’m guessing this is because X11 sends pure rasterized data ( I think, it’s been 15 years since I looked at the X11 protocol), and big blocks of white space (or other non-changing space) can be quickly compressed an extreme amount. A surprising result was the text only, on the raspberry pi compression yielded a slowdown under all text tests, but on the pine64 it showed a slight speed up.
Conclusion:
SSH compression is very useful for large X11 windows with lots of “blank” space even on fast (100M and 1G) LAN connections. There is limited speed up with a pine 64 and some slow down on a raspberry pi with a text only link and a fast connection. The other consideration is that SSH itself used up to 50% of a CPU core when doing the heavy duty compression. This is really not that much even on my 900MHz quad core Raspberry Pi, but it may be a consideration in some CPU intensive applications. If you are running an Arduino X-window over a network, I recommend compression in all cases. (The command for this is SSH -CYX <Hostname> . The -C is for compression and the YX tells ssh to forward X11 graphics)