Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Very simple question with strange effect:

If I run a programm via x-forward it performs very bad when it comes to animations. E.g.:

ssh -X <USER>@<SERVER> "application"

But if I start a remote vnc server and connect to it remotly via ssh, then the animations and all the other stuff runs much smoother. E.g.:

DSPLY=1 && ssh -X <USER>@<SERVER> "vncserver :$DSPLY ; vncviewer localhost:$DSPLY"

In my opinion it is (more or less) the same amount of data which needs to be transmit via ssh. So why is there such a big difference in speed?

share|improve this question
What is the program? What's the latency and bandwidth between your X client and X server? What does xdpyinfo | sed '/^$/q' print? Specifically, does the output include DAMAGE? – Mikel Jan 26 '14 at 18:17
I'm using TCL and TK. But for e.g. MATLAB it's the same. And NO, the output doesn't include DAMAGE. – Tik0 Jan 31 '14 at 7:43

The problem is most likely the X protocol itself. It is very chatty and while the raw amaount of data is rather small, it causes many round trips which become a problem over WAN connections.

Your construct starts a remote xserver which the application you want to use is connecting to. So from the point of view of the application the xserver is local and the round trip delays are small. From an architectural point of view, vnc windows are very simple, hence your vncviewer window needs a lot less chat and round trips to work properly, compared to "real" applications.

Furthermore even the classical vnc implementations target specifically this RTD problem by proactively reducing the required chat, which also results in reduced chat between the vncviewer window and your local xserver.

share|improve this answer
So you say that the VNC window is simple, but when I run the "application" in it, then it has the same complexity. Am I right? In fact, it is (more or less) the same screen which is transportet via "ssh -X", so ssh should be for both transportet screens equal chatty, or not? – Tik0 Jan 28 '14 at 15:08
No, that is not what I said. The application uses the local vncxserver to interact. The vncclient window does not get any more complex with the application in it. In fact, its "complexity" remains the same, whether its a simple xterm, or firefox evolution and gimp overlapping each other – Bananguin Jan 28 '14 at 18:35

Without knowing, I would guess that it comes down to the encryption protocol used. I don't know enough about this to debug it or give you more details but try changing the protocol you use and you will see a great increase in the responsiveness of your exported X programs.

So, instead of ssh -X user@host, try

ssh -YC4c arcfour,blowfish-cbc user@host

For more info, see here (though I recommend using -Y instead of -X for speed).

share|improve this answer
Thanks for the comment, but the parameter doesn't change that much. The essence of my question is, that it does not belong to the shh parameters. For both examples it is just '-X'. – Tik0 Jan 26 '14 at 17:14
@Tik0 did you try connecting with ssh -YC4c arcfour,blowfish-cbc user@host? In my case, I could suddenly use X applications where with ssh -X I couldn't cause they were excruciatingly slow. I am guessing that the vnc protocol handles the encryption better. – terdon Jan 26 '14 at 17:17
Changing the encryption algorithm may make a visible difference (though I wouldn't bet on it, usually the processor is so fast compared to the network that you won't notice anything), but it wouldn't explain a difference between VNC and non-VNC. – Gilles Jan 26 '14 at 23:05

It's likely that VNC is applying some protocol-specific compression. Different VNC implementations default to different compression algorithms, and compression negociation is poorly documented, so it's difficult to be specific.

Try using the -C option to SSH. Depending on the application and on the VNC implementation, it may give better or worse results to VNC, and ssh -C + VNC may be better or worse than VNC alone.

share|improve this answer
But actually the connection does not depend on VNC. The SSH connection is independent from VNC, because the vncviewer runs on the remote server. the resulting window is then streamed via xforward. My question is not:"How get this&that faster". I want to understand why this phenomenon happens. – Tik0 Jan 27 '14 at 12:34

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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