I have a remote machine running Ubuntu 11.10 Server, to which I connect via SSH from OS X 10.7.3:

Host remote.example.com
 ForwardX11 yes
 ForwardX11Trusted yes

Sometimes I want to launch a GUI application there (most notably, gitk). But UI is rather slow. Both remote machine and my own Mac have good internet connection. Ping between them is about 55ms, and there is no packet loss. Is there something I can do to speed things up?

Setting up some other remote desktop solution is an option, but I'd like to avoid it since I don't need this application very often.

  • did you try enabling compression when invoking the application? – Journeyman Geek Mar 18 '12 at 9:53
  • 1
    Thanks. As you can see from my .ssh/config quote, no I did not. I've added Compression yes and CompressionLevel 9 to the host config. It seems a little faster now, but still not enough for comfortable use. Anything else I can do? – Alexander Gladysh Mar 18 '12 at 10:02
  • @AlexanderGladysh What's your upstream speed? – EKW Mar 18 '12 at 10:11
  • scp says 1.2 MB/s when uploading or downloading to that remote machine, which more or less is the number that my ISP advertises. – Alexander Gladysh Mar 18 '12 at 10:33
  • 1
    If it is possible, using sshfs or some other network filesystem and running your application locally would possibly be faster (unless your git repo is truly massive). – Eroen Mar 21 '12 at 15:32

The article Best SSH options for X11 forwarding recommends using instead of the default AES cipher, the arcfour and blowfish ciphers that perform much better.

Therefore one should use :

ssh -c arcfour,blowfish-cbc -XC host.com

Seb's tech notes (if site is down there is an archived version) recommend rather :

ssh -Y -C -o CompressionLevel=9 -c arcfour,blowfish-cbc user@hostname

This might help to improve some more the speed gains that you already observed with compression.

  • 1
    AES, arcfour and blowflish are not compression; they are cryptography. Note that by changing away from AES, you lower the security of the connection; so this might not be feasible in some occasions. The -C option is key here, though, because that's compression. Watch out with setting the Compression level, make sure to measure it as it could have a huge impact on the CPU... – Tamara Wijsman Mar 20 '12 at 16:32
  • Also, some CPUs have hardware acceleration for AES encryption. – rob Mar 21 '12 at 1:06

You mentioned that you don't want to set up some other remote desktop solution but you care about performance. X11 is not a very efficient protocol, so you will only be able to expect minor improvements unless you use a more modern protocol.

NX (NoMachine) is probably your best choice. It still uses ssh, so it shouldn't be too much extra effort compared to other desktop protocols that might require changes to firewall settings, etc. There are NX packages for Fedora, so I presume they are also available for Ubuntu.

If you care enough about performance to take the time to ask the question, then hopefully you can spend a few more minutes to learn NX.

EDIT: To clarify why X11 over ssh will never be fast: the X protocol deals with low-level drawing like lines and circles, and with low-level events such as "the mouse moved 3 pixels to the left." Modern GUI toolkits like GTK and Qt don't draw lines, they draw images. When X11 goes over SSH, it must constantly send image data and low-level mouse events. A high-level protocol like NX, VNC, or Remote Desktop can reduce bandwidth and latency by being aware of how toolkits work. For example, they can avoid the need to send mouse events, they can avoid thousands of redraws when windows are moved, and they can cache areas of the screen like menus. If performance is even a minor concern, raw X11 is always the wrong choice. Fortunately, there are a multitude of fast alternatives that are easy to configure and use.

  • Not that I do not want to use remote desktop, but I would like to try to optimize my X11 connection first :-) Thank you, I will look at NX. – Alexander Gladysh Mar 21 '12 at 4:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.