ssh -X Very slow remotely

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
Im remotely ssh'ing from my linux box at home to my linux box at
school. When using -X and having it open an emacs or DDD window, its
painfully slow to load. It can take 15-20 seconds for the emacs window
to finally pop up. Once its up its fast, but every time it opens a new
one it takes forever. Is there anyway to fix this? This is definitinely
not a network speed issue, as I can download over 500 KB/s from that
computer. Are there any tricks I can do to speed up the -X connection?



Re: ssh -X Very slow remotely wrote:
Quoted text here. Click to load it

Not really an answer to your question, but you could try a vnc
implementation if you want better network performance, since those can
do image compression.

Re: ssh -X Very slow remotely

Steven Mocking wrote:
Quoted text here. Click to load it

Excellent suggestion. I use utlravnc over an ssh tunnel to access my
home computer from work. It's very fast even given that the uplink speed
at home is only 2mb.

Re: ssh -X Very slow remotely

Quoted text here. Click to load it

I have done a lot of X over ssh connections for a long time... and I
would like to third this suggestion.

X over ssh blows.  VNC is tolerable.  And what's invaluable is that a
vnc connection over an ssh connection that drops.... can be easily

Best Regards,
Todd H. /

Re: ssh -X Very slow remotely

Quoted text here. Click to load it

My experience is (somewhat) the reverse -- for text based apps (xterm
or emacs), running over ssh -X is much better/faster than VNC.  Over my
slow home connection (128K), I can use a half-dozen xterms quite well,
but VNC is almost unusable.  The only annoyance is the slow startup time;
creating those xterms requires 10-20 seconds (though I can create them
all at once and then wait, they all show up 10-20 seconds later).  Once
they are created, they work just fine.  Using VNC, you either have extremely
slow updates or lossy image compression (which makes text unreadable).


Re: ssh -X Very slow remotely

Quoted text here. Click to load it

If you are looking for something fast with session overtaking I'd
suggest to take a look at "nomachine" both the commercial version
and the free version "FreeNX". It beats easily the crap out of
anything else in the lines and just needs a single ssh
connection. Meaning it is pretty close to local speed even over
slow connections. I haven't seen anything that can match the
performance, even $$ citrix on doze is slower.

Good luck

Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 308: CD-ROM server needs recalibration

Re: ssh -X Very slow remotely

Quoted text here. Click to load it

Possibilities - most based on the fact that the X protocol isn't very
hungry for bandwidth, but is extremely sensitive to latency.

First, turn off any data compression you may have on ssh. Also, choose
a low-latency encryption and checksumming algorithms, if possible
(ArcFour and MD5 would be good choices to fulfill this criteria).
Data compression has to be off, because to achieve better compression
for the stream, there will often be slight delays where the compressor
is waiting for more data to appear, before sending a data block
(to possibly get a block with more data, in which case it's possible
to achieve higher compression ratios). Without compression, these delays
do not exist.

Colour depth of your X desktop can also matter; even though 8-bit
colour depth looks ugly, it'll decrease packet sizes, and thus decrease

Then, there used to be a thing called 'dxpc' (differential X protocol
compressor), which worked wonders for X connections over dial-up modems
(28kbps or so..). But now, I told to turn off compression, and here
I'm recommneding compression - what gives? The issue is that dxpc is
not a stream compressor, like ssh compression is. Instead, dxpc compression
understands about X network protocol, and can avoid latencies. It also
does cache a number of things (bitmaps, fonts, ...) on the display
side (X server side) of the connection, so these do not need to be
transferred over and over again. Again, largely a latency issue for
todays bandwidth, but can be a significant latency issue.
Wolf  a.k.a.  Juha Laiho     Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
         PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

Site Timeline