ssh -X Very slow remotely - SSH

This is a discussion on ssh -X Very slow remotely - SSH ; 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 ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: ssh -X Very slow remotely

  1. ssh -X Very slow remotely

    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?

    Thanks

    Jeff


  2. Re: ssh -X Very slow remotely

    zooplibob@gmail.com wrote:
    > 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?


    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.

  3. Re: ssh -X Very slow remotely

    Steven Mocking wrote:
    > zooplibob@gmail.com wrote:
    >> 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?

    >
    > 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.


    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.

  4. Re: ssh -X Very slow remotely

    Chuck writes:

    > Steven Mocking wrote:
    > > zooplibob@gmail.com wrote:
    > >> 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?

    > >
    > > 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.

    >
    > 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.


    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
    reconnected.

    Best Regards,
    --
    Todd H.
    http://www.toddh.net/

  5. Re: ssh -X Very slow remotely

    comphelp@toddh.net (Todd H.) wrote in news:84irgmhud7.fsf@ripco.com:
    > 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
    > reconnected.


    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).

    -chris

  6. Re: ssh -X Very slow remotely

    In comp.security.ssh Chris Dodd :
    > comphelp@toddh.net (Todd H.) wrote in news:84irgmhud7.fsf@ripco.com:
    >> 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
    >> reconnected.


    > 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).


    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

  7. Re: ssh -X Very slow remotely

    "zooplibob@gmail.com" said:
    >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.


    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
    latency.

    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)

+ Reply to Thread