SSH compression for X11 forwarding

Question

I’m on the East coast of the United States, SSHing into a server on the West coast.

I’ve managed to get X11 forwarding working so I can launch GUI apps for certain tasks where it’s helpful. However, for all the X11-forwarded apps (especially emacs!), there is so much lag between input (keystrokes, mouse clicks, etc.) and response that it sometimes goes from being incredibly frustrating to potentially harmful—when I intend to do A, but B happens because the lag is so great.

Is SSH compression a potential culprit? What kind of compression should I be using?

score 20 · Accepted Answer · answered Oct 19 '12 at 16:08

20

X11 graphics take up a lot of bandwidth. If your remote host is some distance away (i.e. not on the LAN), then you'll probably suffer sluggishness in your exported X11 applications.

I'm not sure about SSH compression. Performance may depend on other factors, such as CPU performance. From the ssh man page:

     -C      Requests compression of all data (including stdin, stdout,
             stderr, and data for forwarded X11 and TCP connections).  The
             compression algorithm is the same used by gzip(1), and the
             “level” can be controlled by the CompressionLevel option for pro‐
             tocol version 1.  Compression is desirable on modem lines and
             other slow connections, but will only slow down things on fast
             networks.  The default value can be set on a host-by-host basis
             in the configuration files; see the Compression option.

Here are some other workarounds you can use to make things faster:

Instead of interacting with the GUI using X11 forwarding, consider something else that has better optimization/compression, such as VNC or NX/FreeNX.
Use the terminal version of emacs instead of the GUI version.

answered Oct 19 '12 at 16:08

padub

324
2
3

1

Guess my problem isn’t about configuration—it’s about the tools I chose. I had some trouble getting VNC to work before, but maybe it’s worth another shot. Thanks! – Zearin Oct 19 '12 at 17:19
5

Actually well written X11 programs don't comsume a lot of bandwidth. The main issue with X11 is the abysmal badly written Xlib which performs a full synchronous roundtrip for almost every operation, while many operations could be performed asynchronously. If using another X11 protocol backend, like Xcb and not doing moronic things like rasterizing the whole GUI on the client and then just blitting the damn thing over the network, plain X11 over TCP over a low bandwidth, high latency connection is actually very usable. However many programs are written badly. I recommend NX or ssh attached Xpra – datenwolf Oct 22 '12 at 17:22
1

+1 to @datenwolf It's more about latency and number o roundtrips than bandwith, and Xlib is doing very bad job in utilising full duplex async nature of x11 protocol (protocol itself is very optimised for latency) – Andrey Sidorov Dec 18 '12 at 05:15
3

Despite what the SSH documentation says about the downside of compression using the -C option, I have found that it has always improved X11 forwarding performance. This does not mean it's great, but it's better than near unusable. I'm not sure why it would slow things down on a fast network. Maybe this documentation was written in the 1990's before they invented fast computers. – Noah Spurrier Jul 06 '16 at 23:30
2

I can confirm Noah Spurrier's comments- -C resulted in Firefox using 20 - 30 Mbps instead of 120 Mbps on my LAN, and it was more responsive. – danno Apr 16 '20 at 02:48
@NoahSpurrier , I would say that `ssh` is used mostly as remote shell. And in such case the compression applied to keystrokes user types and echo they get in command prompt may introduce noticeable uncomfortable delays. So I guess this is why compression is disabled by default. If someone need to use sshfs or similar then they can obviously enable compression. I never actually tried compression before and never noticed delays. I also use `tmux` everywhere. And it has some special output buffering which I believe drops some fast stdout "frames" which user would not notice anyway. – Victor Yarema Feb 05 '21 at 07:36

score 4 · Answer 2 · answered Jun 22 '16 at 17:48

As you specifically mentioned emacs: there is the command-line option

  -nw, --no-window-system
          Tell Emacs not to create a graphical frame.  If you  use
          this switch when invoking Emacs from an xterm(1) window,
          display is done in that window.

This can be much faster when working over ssh (as it only has to transfer character, not redraw the whole screen over X11).

SSH compression for X11 forwarding

2 Answers2