SSH GUI slow - SSH

This is a discussion on SSH GUI slow - SSH ; I used ssh -X to login and remotely run Matlab. The problem is the performance is very slow. For example, if I minimize and then unminimize the Matlab GUI, it takes about 11 seconds to repaint the window. This happens ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: SSH GUI slow

  1. SSH GUI slow


    I used ssh -X to login and remotely run Matlab. The problem is the
    performance is very slow. For example, if I minimize and then unminimize
    the Matlab GUI, it takes about 11 seconds to repaint the window. This
    happens when I ssh within the same server so the slowdown isn't caused by
    the physical networking. Also, as a test I ran Pan and Evolution and the
    performance was great - I couldn't tell that I was using ssh remotely
    with those
    applications.

    Is this slowdown caused by Matlab and maybe other programs like it? Is
    something wrong with my configuration to cause it to run slowly ?

    Any ideas would be appreciated.

    Thank you,
    Curt

  2. Re: SSH GUI slow

    On 2008-05-09, curt <97WideGlide@cox.net.invalid> wrote:
    >
    > I used ssh -X to login and remotely run Matlab. The problem is the
    > performance is very slow. For example, if I minimize and then unminimize
    > the Matlab GUI, it takes about 11 seconds to repaint the window. This
    > happens when I ssh within the same server so the slowdown isn't caused by
    > the physical networking. Also, as a test I ran Pan and Evolution and the
    > performance was great - I couldn't tell that I was using ssh remotely
    > with those
    > applications.
    >
    > Is this slowdown caused by Matlab and maybe other programs like it? Is
    > something wrong with my configuration to cause it to run slowly ?
    >
    > Any ideas would be appreciated.
    >

    This is not an ssh problem; this is an X problem with Matlab. An X client
    connected to the X server over a network has much greater delays than
    one that runs locally. If the X client is written inefficiently, this
    can result in it running quite slowly. There's not much you can do other
    than ask Matlab to write better interface code in their next release.

    --
    Christopher Mattern

    NOTICE
    Thank you for noticing this new notice
    Your noticing it has been noted
    And will be reported to the authorities

  3. Re: SSH GUI slow

    On Fri, 09 May 2008 10:02:28 -0500, Chris Mattern wrote:

    > There's not much you can do
    > other than ask Matlab to write better interface code in their next
    > release.


    Thank you for your response.

    Please note that I am not connected "over a network". I am using the SSH
    tunnel to connect to localhost so that physical networking is not an
    issue.

    I initially thought Matlab was the problem but I was very surprised to
    think that inefficient code can cause a GUI to run 10-15 times more
    slowly simply because it is being piped through ssh. I mean, nothing
    really changes except that the ssh tunnel is inserted into the equation,
    right ? The XWindow system is exactly the same, the hardware/driver
    configuration is exactly the same and the application is exactly the
    same. The only difference is the way these (and other) subsystems are
    working together via ssh.

    I've got to think that there is something else going on here.

    Thanks again,
    Curt



  4. Re: SSH GUI slow

    On Fri, 09 May 2008 15:31:22 GMT curt <97WideGlide@cox.net.invalid> wrote:

    | I initially thought Matlab was the problem but I was very surprised to
    | think that inefficient code can cause a GUI to run 10-15 times more
    | slowly simply because it is being piped through ssh. I mean, nothing
    | really changes except that the ssh tunnel is inserted into the equation,
    | right ? The XWindow system is exactly the same, the hardware/driver
    | configuration is exactly the same and the application is exactly the
    | same. The only difference is the way these (and other) subsystems are
    | working together via ssh.

    When it's not going through SSH, the difference between 1ms and 15ms to update
    a window won't be noticed. This difference would be a function how much data
    the application is sending through. In X, it can be a lot. If it refreshes
    more window contents and not just the little bit that changes, that volume of
    data can be a big load. SSH would have to encrypt all of that data. Have you
    tried compression to see if it might help?


    | I've got to think that there is something else going on here.

    That's always possible. But I've used X over SSH before and found it slow
    for some applications. It's not as bad as when I used X over a dialup.
    In the case of dialup I could really see which apps were problematic.
    For some, updates over dialup were in minutes, not seconds.

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  5. Re: SSH GUI slow

    On Mon, 12 May 2008 08:57:31 +0000, phil-news-nospam wrote:

    > On Fri, 09 May 2008 15:31:22 GMT curt <97WideGlide@cox.net.invalid>
    > wrote:
    >
    > | I initially thought Matlab was the problem but I was very surprised to
    > | think that inefficient code can cause a GUI to run 10-15 times more |
    > slowly simply because it is being piped through ssh. I mean, nothing |
    > really changes except that the ssh tunnel is inserted into the equation,
    > | right ? The XWindow system is exactly the same, the hardware/driver |
    > configuration is exactly the same and the application is exactly the |
    > same. The only difference is the way these (and other) subsystems are |
    > working together via ssh.
    >
    > When it's not going through SSH, the difference between 1ms and 15ms to
    > update a window won't be noticed. This difference would be a function
    > how much data the application is sending through. In X, it can be a
    > lot. If it refreshes more window contents and not just the little bit
    > that changes, that volume of data can be a big load. SSH would have to
    > encrypt all of that data. Have you tried compression to see if it might
    > help?
    >
    >
    > | I've got to think that there is something else going on here.
    >
    > That's always possible. But I've used X over SSH before and found it
    > slow for some applications. It's not as bad as when I used X over a
    > dialup. In the case of dialup I could really see which apps were
    > problematic. For some, updates over dialup were in minutes, not seconds.



    It is not 1 milisecond versus 15 miliseconds. It is 2 seconds versus
    about 25 seconds which is very noticable. And it doesn't make any sense
    to me. Dialup, Highspeed, Cable, etc are not an issue. I am connecting
    to the same computer (client and server are the exact same machine). The
    only slowdown could be due to the logical networking within the machine.
    Where could this bottleneck be ?

  6. Re: SSH GUI slow

    On Mon, 12 May 2008 19:56:55 GMT curt <97WideGlide@cox.net.invalid> wrote:
    | On Mon, 12 May 2008 08:57:31 +0000, phil-news-nospam wrote:
    |
    |> On Fri, 09 May 2008 15:31:22 GMT curt <97WideGlide@cox.net.invalid>
    |> wrote:
    |>
    |> | I initially thought Matlab was the problem but I was very surprised to
    |> | think that inefficient code can cause a GUI to run 10-15 times more |
    |> slowly simply because it is being piped through ssh. I mean, nothing |
    |> really changes except that the ssh tunnel is inserted into the equation,
    |> | right ? The XWindow system is exactly the same, the hardware/driver |
    |> configuration is exactly the same and the application is exactly the |
    |> same. The only difference is the way these (and other) subsystems are |
    |> working together via ssh.
    |>
    |> When it's not going through SSH, the difference between 1ms and 15ms to
    |> update a window won't be noticed. This difference would be a function
    |> how much data the application is sending through. In X, it can be a
    |> lot. If it refreshes more window contents and not just the little bit
    |> that changes, that volume of data can be a big load. SSH would have to
    |> encrypt all of that data. Have you tried compression to see if it might
    |> help?
    |>
    |>
    |> | I've got to think that there is something else going on here.
    |>
    |> That's always possible. But I've used X over SSH before and found it
    |> slow for some applications. It's not as bad as when I used X over a
    |> dialup. In the case of dialup I could really see which apps were
    |> problematic. For some, updates over dialup were in minutes, not seconds.
    |
    |
    | It is not 1 milisecond versus 15 miliseconds. It is 2 seconds versus
    | about 25 seconds which is very noticable. And it doesn't make any sense
    | to me. Dialup, Highspeed, Cable, etc are not an issue. I am connecting
    | to the same computer (client and server are the exact same machine). The
    | only slowdown could be due to the logical networking within the machine.
    | Where could this bottleneck be ?

    SSH is always going to add some overhead. If without it the delay is already
    2 seconds, then the application is overloading it, if that's on the same host.
    Then adding encryption _and_ decryption to that (both on the same machine in
    the case of localhost), the added delay does not surprise me since 2 seconds
    is telling me there is an excess of data being sent.

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  7. Re: SSH GUI slow

    On Wed, 14 May 2008 10:46:39 +0000, phil-news-nospam wrote:

    > On Mon, 12 May 2008 19:56:55 GMT curt <97WideGlide@cox.net.invalid>
    > wrote: | On Mon, 12 May 2008 08:57:31 +0000, phil-news-nospam wrote: |
    > |> On Fri, 09 May 2008 15:31:22 GMT curt <97WideGlide@cox.net.invalid>
    > |> wrote:
    > |>
    > |> | I initially thought Matlab was the problem but I was very surprised
    > to |> | think that inefficient code can cause a GUI to run 10-15 times
    > more | |> slowly simply because it is being piped through ssh. I mean,
    > nothing | |> really changes except that the ssh tunnel is inserted into
    > the equation, |> | right ? The XWindow system is exactly the same, the
    > hardware/driver | |> configuration is exactly the same and the
    > application is exactly the | |> same. The only difference is the way
    > these (and other) subsystems are | |> working together via ssh.
    > |>
    > |> When it's not going through SSH, the difference between 1ms and 15ms
    > to |> update a window won't be noticed. This difference would be a
    > function |> how much data the application is sending through. In X, it
    > can be a |> lot. If it refreshes more window contents and not just the
    > little bit |> that changes, that volume of data can be a big load. SSH
    > would have to |> encrypt all of that data. Have you tried compression
    > to see if it might |> help?
    > |>
    > |>
    > |> | I've got to think that there is something else going on here. |>
    > |> That's always possible. But I've used X over SSH before and found it
    > |> slow for some applications. It's not as bad as when I used X over a
    > |> dialup. In the case of dialup I could really see which apps were |>
    > problematic. For some, updates over dialup were in minutes, not seconds.
    > |
    > |
    > | It is not 1 milisecond versus 15 miliseconds. It is 2 seconds versus
    > | about 25 seconds which is very noticable. And it doesn't make any
    > sense | to me. Dialup, Highspeed, Cable, etc are not an issue. I am
    > connecting | to the same computer (client and server are the exact same
    > machine). The | only slowdown could be due to the logical networking
    > within the machine. | Where could this bottleneck be ?
    >
    > SSH is always going to add some overhead. If without it the delay is
    > already 2 seconds, then the application is overloading it, if that's on
    > the same host. Then adding encryption _and_ decryption to that (both on
    > the same machine in the case of localhost), the added delay does not
    > surprise me since 2 seconds is telling me there is an excess of data
    > being sent.


    Ugh, I'm sorry, I'm probably not describing the situation very well.
    When I said it takes 2 seconds to start up, I meant that the total
    startup time was 2 seconds. I should have described just the time it
    takes to redraw the screen.

    If I'm not using "ssh -X" and I simply minimize the Matlab window and
    then unminimize it again, redrawing is instantaneous. The screen pops
    right back up. However, when I am using "ssh -X" (even on the local
    system) it takes 8-9 seconds to just redraw the screen. I get the
    outline of the window but the contents don't appear and the window
    doesn't accept input for a while. My question is how can this
    application be slowed down this much just from using ssh ? And a second
    question is what tools are available to me to find out exactly where the
    bottle neck is ?



  8. Re: SSH GUI slow

    Hello,

    curt wrote:

    > If I'm not using "ssh -X" and I simply minimize the Matlab window and
    > then unminimize it again, redrawing is instantaneous. The screen pops
    > right back up. However, when I am using "ssh -X" (even on the local
    > system) it takes 8-9 seconds to just redraw the screen. I get the
    > outline of the window but the contents don't appear and the window
    > doesn't accept input for a while. My question is how can this
    > application be slowed down this much just from using ssh ? And a
    > second question is what tools are available to me to find out exactly
    > where the bottle neck is ?


    Whithout ssh -X the communication between the X server and the
    application uses fast IPC techniques, and synchronization just involves
    a single OS kernel. With ssh -X, all data has to be serialized through
    some communication channel, and the synchronization between the
    processes happens through the same channel, which might easily increase
    the latency by some considerable factor.

    If an app does not make sure there is not too much synchronization, then
    it can easily become a problem when using X over a network,
    independently from ssh. My favourite example for this situation is
    dragging objects around with constant redraw. Imagine a polygon where
    one node is dragged around and the polygon is kept up to date all the
    time. This produces lots of communication over a network. I'm pretty
    sure there is nothing ssh could do here. There are optimized protocols
    for remote displays, see NoX, working over ssh as well.

    Bernd Strieder


  9. Re: SSH GUI slow

    On Wed, 14 May 2008 12:53:53 GMT curt <97WideGlide@cox.net.invalid> wrote:

    | Ugh, I'm sorry, I'm probably not describing the situation very well.
    | When I said it takes 2 seconds to start up, I meant that the total
    | startup time was 2 seconds. I should have described just the time it
    | takes to redraw the screen.
    |
    | If I'm not using "ssh -X" and I simply minimize the Matlab window and
    | then unminimize it again, redrawing is instantaneous. The screen pops
    | right back up. However, when I am using "ssh -X" (even on the local
    | system) it takes 8-9 seconds to just redraw the screen. I get the
    | outline of the window but the contents don't appear and the window
    | doesn't accept input for a while. My question is how can this
    | application be slowed down this much just from using ssh ? And a second
    | question is what tools are available to me to find out exactly where the
    | bottle neck is ?

    One "tool" is to try a faster CPU. If a faster CPU handles this quicker, the
    CPU utilization is at least one bottleneck.

    You can gain some network performance by having it all on the same machine.
    But you in turn lose CPU because you are doing both the encryption as well
    as the decryption on the same machine, needing even more of its CPU speed.
    Trying this between two like machines may help give some insight.

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  10. Re: SSH GUI slow

    On Wed, 14 May 2008 17:12:29 +0000, phil-news-nospam wrote:

    > You can gain some network performance by having it all on the same
    > machine. But you in turn lose CPU because you are doing both the
    > encryption as well as the decryption on the same machine, needing even
    > more of its CPU speed.


    Thanks for your response.

    I loaded up System Monitor and although some CPUs spike to 80% twice for
    just a fraction of a second the rest of the time none of them are over
    10% utilized. As it is working on redrawing the screen, System Monitor
    seems to show a completely idle system.

    The machine I'm testing on has 8 extreme cores and 32Gig of main memory.

    I'm puzzled.

  11. Re: SSH GUI slow

    phil-news-nospam@ipal.net wrote:
    > On Wed, 14 May 2008 12:53:53 GMT curt <97WideGlide@cox.net.invalid> wrote:
    >
    > | Ugh, I'm sorry, I'm probably not describing the situation very well.
    > | When I said it takes 2 seconds to start up, I meant that the total
    > | startup time was 2 seconds. I should have described just the time it
    > | takes to redraw the screen.
    > |
    > | If I'm not using "ssh -X" and I simply minimize the Matlab window and
    > | then unminimize it again, redrawing is instantaneous. The screen pops
    > | right back up. However, when I am using "ssh -X" (even on the local
    > | system) it takes 8-9 seconds to just redraw the screen. I get the
    > | outline of the window but the contents don't appear and the window
    > | doesn't accept input for a while. My question is how can this
    > | application be slowed down this much just from using ssh ? And a second
    > | question is what tools are available to me to find out exactly where the
    > | bottle neck is ?
    >
    > One "tool" is to try a faster CPU. If a faster CPU handles this quicker, the
    > CPU utilization is at least one bottleneck.
    >
    > You can gain some network performance by having it all on the same machine.
    > But you in turn lose CPU because you are doing both the encryption as well
    > as the decryption on the same machine, needing even more of its CPU speed.
    > Trying this between two like machines may help give some insight.
    >

    Just wanted to jump on curts bandwagon,we are having this problem as
    well, and as much as I wish it was matlabs problem(we pay for support so
    they would have to fix it) it seems likely that it is not.

    If the machine running matlab and sshd is running fedora 6, the gui is
    very snappy there is almost no difference whatsoever, but as soon as you
    upgrade to Fedora 8 or Fedora 9 then suddenly the gui is too slow to
    use. I am still trying to narrow down whether this is because of a
    different version of ssh or a different way that the windows are being
    drawn in Fedora 8. (Compiz is disabled and I have the latest JRE).

    Also it seems to be on the server end because when I use OSX X11 again
    it works snappy if being served from a Fedora 6, but slow as heck on a
    Fedora 8.

    So I guess the question is , has there been any big changes to ssh since
    Fedora 6?
    And Curt one temporary fix may be to use a Fedora 6 Installation on your
    server.

    Let me know what you guys think.

    -Rob


  12. Re: SSH GUI slow

    curt <97WideGlide@cox.net.invalid> said:
    >If I'm not using "ssh -X" and I simply minimize the Matlab window and
    >then unminimize it again, redrawing is instantaneous. The screen pops
    >right back up. However, when I am using "ssh -X" (even on the local
    >system) it takes 8-9 seconds to just redraw the screen. I get the
    >outline of the window but the contents don't appear and the window
    >doesn't accept input for a while. My question is how can this
    >application be slowed down this much just from using ssh ? And a second
    >question is what tools are available to me to find out exactly where the
    >bottle neck is ?


    Redraw (or pretty much any "high level" operation in X) results in
    quite a huge bunch of X-protocol level request/response pairs. Many
    of these operations are very small in terms of amount of data
    transferred. Latency for these requests is much more critical than
    bandwidth.

    The data compression done by ssh can cause significant latency for
    these small requests (and responses as well), as the compression
    works best by being able to compress complete blocks of data (the
    size of the block being defined by the ssh compression implementation).
    What ssh does when it doesn't get a full block to transfer is that it
    will wait for more data to arrive -- and transmit partial blocks only
    after a significant timeout. This timeout is small enough to be more
    or less unnoticeable when typing at a terminal session, but is big
    enough to cause havoc when communicating using the X protocol. It might
    also be that ssh does some expedited transmissions of partial blocks
    when used as the terminal channel, as opposed to when used as a tunnel.

    The compression in ssh can (in the clients I've encountered) be disabled
    in configuration, which will get you rid of this latency. There's still
    some latency in the encryption layer, but it's more tolerable than the
    latency caused by the compression level.

    Beyond that, there is at least "dxpc" (differential X protocol
    compressor), which in addition to "intelligently" compressing X
    requests will also act as a cache so that the number of requests
    across the communication link is reduced. At least back when I
    had the need to occasionally run X applications (such as HP OpenView)
    over a 33.6kbit/s dialup, the dxpc really did save the day.
    --
    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)

  13. Re: SSH GUI slow

    On Fri, 16 May 2008 08:51:40 -0500 Rob wrote:

    | So I guess the question is , has there been any big changes to ssh since
    | Fedora 6?
    | And Curt one temporary fix may be to use a Fedora 6 Installation on your
    | server.

    I've been doing system backups via SSH for years and I have not seen any
    slowdown on the latest version. These backups pump 10 to 30 GB through SSH
    on a number of different machines every day. The only think I'm having
    troubles with is rsync not handling tens of millions of files very well.
    I'm designing a new protocol for that which won't require gathering the
    whole tree all at once.

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  14. Re: SSH GUI slow

    On Sun, 18 May 2008 17:12:03 GMT Juha Laiho wrote:

    | Redraw (or pretty much any "high level" operation in X) results in
    | quite a huge bunch of X-protocol level request/response pairs. Many
    | of these operations are very small in terms of amount of data
    | transferred. Latency for these requests is much more critical than
    | bandwidth.
    |
    | The data compression done by ssh can cause significant latency for
    | these small requests (and responses as well), as the compression
    | works best by being able to compress complete blocks of data (the
    | size of the block being defined by the ssh compression implementation).
    | What ssh does when it doesn't get a full block to transfer is that it
    | will wait for more data to arrive -- and transmit partial blocks only
    | after a significant timeout. This timeout is small enough to be more
    | or less unnoticeable when typing at a terminal session, but is big
    | enough to cause havoc when communicating using the X protocol. It might
    | also be that ssh does some expedited transmissions of partial blocks
    | when used as the terminal channel, as opposed to when used as a tunnel.
    |
    | The compression in ssh can (in the clients I've encountered) be disabled
    | in configuration, which will get you rid of this latency. There's still
    | some latency in the encryption layer, but it's more tolerable than the
    | latency caused by the compression level.

    That probably explains why my backups don't have any problems from SSH.
    Although I do use compression for most of them, rsync generally pushes a
    lot of data through rather fast without a lot of responses needed and so
    bypasses that tiny delay.


    | Beyond that, there is at least "dxpc" (differential X protocol
    | compressor), which in addition to "intelligently" compressing X
    | requests will also act as a cache so that the number of requests
    | across the communication link is reduced. At least back when I
    | had the need to occasionally run X applications (such as HP OpenView)
    | over a 33.6kbit/s dialup, the dxpc really did save the day.

    Nice. I never knew about that. I'll have to look it up.

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  15. Re: SSH GUI slow

    On Fri, 09 May 2008 04:02:50 +0000, curt wrote:

    > I used ssh -X to login and remotely run Matlab. The problem is the
    > performance is very slow. For example, if I minimize and then
    > unminimize the Matlab GUI, it takes about 11 seconds to repaint the
    > window. This happens when I ssh within the same server so the slowdown
    > isn't caused by the physical networking. Also, as a test I ran Pan and
    > Evolution and the performance was great - I couldn't tell that I was
    > using ssh remotely with those
    > applications.
    >
    > Is this slowdown caused by Matlab and maybe other programs like it? Is
    > something wrong with my configuration to cause it to run slowly ?
    >
    > Any ideas would be appreciated.
    >
    > Thank you,
    > Curt


    Thanks to everyone for their responses to my original question.

    The only solution I found to work was FreeNX which is a free remote
    display solution based on NoMachine's core libraries. Getting it to work
    well was slightly difficult but now that it is running, it is very fast
    for whatever applications I need to use remotely. I never figured out
    conclusively why ssh -X was so slow or how to speed it up at all. If
    someone wants to do this I would look at Juha Laiho's post here - he
    seemed to be right on.

    Thanks,
    Curt

+ Reply to Thread