SSH X11 forwarding is extremely slow over VPN

openvpnsshx11forwarding

I'm using an VPN (with OpenVPN) to keep access between my home and work computers, and today I tried to ssh-forward an app which is GUI-only, and I found this to be terribly slow. I've used SSH X11 forwarding before, and it indeed has latency, but between this two hosts its really big. It takes around 20 seconds between the click of a button and the output being shown on the local machine.

I have rtt min/avg/max/mdev = 84.393/86.858/91.297/3.163 ms latency between this two hosts, and the SSH connection gives me around 1.2MiB/s, which I think it should be more than enough :\

I'm using -YCX, and I've experimentally tried with and without Y and C (openvpn already compresses stuff with lzo), as well as diferent ciphers, with similar results.

I'm starting to think it might be the GTK theme, which could be really heavy or something.

Does anybody know if this is normal, and what could I do to get less latency? (3-5s could be bearable, but 20 is way too much)

Best Answer

The problem with forwarding contemporary X (not that "old" X when its network transparency was invented) is with font smoothing: to properly smooth each glyph of text rendered on some surface, the X server has to get the bitmap which is located under the bounding box of that glyph from the client which wishes to render that glyph. (This is neede for the smoothing algorythm to work properly as it takes the context on which the glyph is rendered into account.)

Hence with contemporary GUI toolkits the amount of traffic shoveled between the X server and its clients is huge: you can see this by enabling TCP in your local X server (these days they are typically started with -nolisten tcp) and force some GTK- or Qt-based X client to talk to the server via TCP:

$ DISPLAY=localhost:x11 /usr/bin/that/x-app

(see grep x11 </etc/services for the X server's standard ports). You will immediately notice how sluggishly that client behaves even though the X traffic is not leaving the local host: that's simply because normally the X traffic is carried over a Unix-domain socket which basically just copies bytes between buffers in memory, thus having quite low overhead, and now it traverses the full TCP/IP stack with all its queues and complicated logic. Now consider what happens when this traffic is sent in your case—wrapped in three layers of data transfer protocols: SSH tunnel carried by VPN tunnel carried by TCP/IP carried by the wire.

As to what to do about this, I'm not so sure.

With mosh being out of the game, I'd try playing with the IPQoS option of the OpenSSH client.

Another approach is to attack the problem from another angle: try VNC-based access to your application. Options vary here:

  • You can start simply by exporting the whole display via x11nvc or something like this.
  • Use software packages which are able to "export" specific application or window—Xpra and winswitch.
  • Try a more heavy-weight though complete solution such as X2Go.
Related Topic