SSH X11 forwarding has delay

Atomicdog,

Have a look at my post and tell me if you think they are a little similar? My problem is that SSH terminal basically freezes up when browser data is forwarded through it.

If I wait long enough and don't use the browser (socks mode), then the SSH term goes back to normal and accepts input again.

http://www.linode.com/forums/viewtopic.php?t=4806

Is your SSHD port set to one above 1024? Try one below if so… see if it makes a difference.

Yeah, I saw your post out there, but I don't think it's the same because yours always works fine at first and mine always has a delay initially. Yours seems more intermittent.

SSHD is running on the standard port. Unfortunately, I can't even narrow this down as to whether it is something that needs to be changed on the SSHD side or the XMing side yet… :?

Here is some useful information from an ltrace of xv:

% time     seconds  usecs/call     calls      function
------ ----------- ----------- --------- --------------------
 47.68  152.597617      198694       768 XGetImage
 39.68  126.984018      165343       768 XAllocColor
  3.74   11.980527      630554        19 XNextEvent
  2.58    8.256200      550413        15 XSync
  2.54    8.139029     4069514         2 XPutImage
  ...

Investigating why this is so slow…

Tried removing xcb, per https://bugs.launchpad.net/ubuntu/+bug/241063

$ ldd `which xv`
    linux-gate.so.1 =>  (0xb7fae000)
    libz.so.1 => /lib/libz.so.1 (0xb7f94000)
    libX11.so.6 => /usr/lib/libX11.so.6 (0xb7e73000)
    libm.so.6 => /lib/libm.so.6 (0xb7e4c000)
    libjpeg.so.7 => /usr/lib/libjpeg.so.7 (0xb7e15000)
    libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7df0000)
    libtiff.so.3 => /usr/lib/libtiff.so.3 (0xb7d9a000)
    libc.so.6 => /lib/libc.so.6 (0xb7c2e000)
    libXau.so.6 => /usr/lib/libXau.so.6 (0xb7c2a000)
    libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7c24000)
    libdl.so.2 => /lib/libdl.so.2 (0xb7c1f000)
    /lib/ld-linux.so.2 (0xb7faf000)

This did not fix the issue.

Sniffing the network shows that during the long delay period, I am getting lots of very small packets sent back and forth across the tunnel.

The following is an example of log messages that occur for the majority of the wait time.

 <linode>--> <client>    SSH Encrypted response packet len=68
 <client>--> <linode>    SSH Encrypted request packet len=84
 <linode>--> <client>    SSH Encrypted response packet len=100
 <client>--> <linode>    SSH Encrypted request packet len=84</linode></client></client></linode></linode></client></client></linode>

@AtomicDog:

I have enabled X11 forwarding in my SSHD config and am tunneling my connection using PuTTY along with Xming to display. When I run xv there is a huge initial delay.

…

If I run xclock, it takes about 1 second for the window to appear.

Any ideas?
The X protocol has been described as the worst remote display solution, except for every other one. It's not so much that it works badly, but everything else works worse.

If you're X tunnelling then your remote X application is talking to your local X server (your desktop). Starting up an application can involve a lot of small requests from the application to the server (your desktop), and a lot of communication back from the server to the application. If your home upload speed is slow or saturated then this can cause massively long application startup delays, depending on the number of widgets in the application, and so on.

In 1995 I attempted to run Netscape - I forget which ancient version - remotely; my local machine was a Sparc IPC and the machine running netscape was a Sparc 4. The connection… a 28.8K PPP modem dialup. It took over 10 minutes for the application to start (a lot of resources got thrown over the modem link; it was 100% busy), but once it had started then it was actually quite usable. I think you may be seeing similar.

X is a great protocol in that remote programs are considered equivalent in terms of desktop access; whether a program runs on your local machine, a LAN away, a WAN away, over the internet… they all interact similarly to the X server and are equal. This si why all other remote desktop solutions are worse. Unfortunately the result can be painfully slow startup times and network intensive communication; this is why X is the worst.

(Ok, that hasn't helped you….)

You might want to look into an X protocol analyser (google for one); this can tell you what X calls the application is making and might give you an idea of the problem. You might also want to consider a different remote display technology where a remote desktop is displayed as blocks (eg VNC). It's not as well integrated into your desktop, but may be faster.

NX may also be an option. I haven't used it other than to play around with connecting to NoMachine's demo server, but it was actually usable over a dialup link.

Some more reading:

http://tuxarena.blogspot.com/2009/04/co … chine.html">http://tuxarena.blogspot.com/2009/04/connect-remotely-to-your-linux-machine.html

http://www.linuxplanet.com/linuxplanet/ … ls/6567/1/">http://www.linuxplanet.com/linuxplanet/tutorials/6567/1/

http://www.ubuntugeek.com/how-to-setup- … repid.html">http://www.ubuntugeek.com/how-to-setup-freenx-server-and-client-in-ubuntu-810-intrepid.html

http://www.linux.com/archive/feature/116354

NX works significantly better than standard X forwarding over WANs.

I realize that X forwarding may not be the best solution for remote control of a desktop.

The reason I want to use X forwarding, though, is to view image attachments easily. I could set up xv in my mailcap, and then it would display the images locally on my PC as long as I have PuTTY with X11 Forwarding configured correctly. This would be better for me than trying to use a VNC client just to check my e-mail. I am not even running an X desktop.

I am using a cable modem, not a dialup connection, and I would think the bandwidth would be more than sufficient.

I just ran another ltrace on a 1 pixel jpeg (631 bytes):

% time     seconds  usecs/call     calls      function
------ ----------- ----------- --------- --------------------
 47.48  148.659076      193566       768 XAllocColor
 45.36  142.018798      184920       768 XGetImage
  3.02    9.444790     1049421         9 XNextEvent
  2.81    8.811661      244768        36 XGetNormalHints
  0.72    2.252987      375497         6 XInternAtom

I think the issue is that it is making a crazy amount of roundtrips on startup, so the latency is adding up. I am not sure if I can somehow adjust this with a buffer setting or if this is just the way the X protocol is designed.

I looked into an X protocol analyzer but I didn't see one available for Windows…

Maybe I just need to switch to a different program…

This URL had some relevant discussion.

http://fixunix.com/xwindows/358974-xquerycolor.html

I'm not too familiar with netcat, but perhaps something like this might serve your needs rather than using X?

desktop$ while true ; do nc -l 12345 | display - ; done &
desktop$ ssh -R 12345:localhost:12345 user@linode.example.net

Then you could have your mail reader run this instead of xv:

linode$ nc 12345 < image.jpg

Not sure exactly if the way display handles standard input would allow this, but may be worth trying.

Failing that, it seems like there must be some image viewer out there that will accept images being pushed to it over a network port.

nx still forwards NX, but it does compression and caching to eliminate most of the X round-trips:

http://en.wikipedia.org/wiki/NX_technology

It's generally a lot faster than VNC while providing similar functionality to X. You can forward just a single app (or all apps).

For example, when my friend comes over to my house to do some coding, he fires up NX and connects to his box back home. Up on his Windows desktop pops up KDevelop, kate, konsole, etc. They each show up as separate windows, as if they were local apps.

Yeah, I could use something like netcat to shove the data back and forth over the connection, but it's a little kludgy.

Honestly, after more investigation it seems like those programs are just using a poor implementation for running via remote X. (If you are using a TrueColor display, for example, I don't think that there is a need to make all those round trips for XAllocColor.)

ltrace -c xv -vis TrueColor test.JPG

% time     seconds  usecs/call     calls      function
------ ----------- ----------- --------- --------------------
 47.27  143.337947      186637       768 XGetImage
 45.87  139.092035      181109       768 XAllocColor
  2.89    8.770029      243611        36 XGetNormalHints
  1.92    5.814834      581483        10 XNextEvent
  0.93    2.809923      255447        11 XSync

I just installed gpicview and it opens the 50k JPG file in around 4 seconds. I guess that would be my recommendation for anyone else wanting this functionality.

@Guspaz:

nx still forwards NX, but it does compression and caching to eliminate most of the X round-trips:

http://en.wikipedia.org/wiki/NX_technology

It's generally a lot faster than VNC while providing similar functionality to X. You can forward just a single app (or all apps).

For example, when my friend comes over to my house to do some coding, he fires up NX and connects to his box back home. Up on his Windows desktop pops up KDevelop, kate, konsole, etc. They each show up as separate windows, as if they were local apps.

Thanks. NX looks interesting…I didn't realize it forwarded X so it should work with all X applications. Looks like you need a software component on both sides, though. If I want to run more robust X applications remotely in the future I will probably look into using this.

@AtomicDog:

Thanks. NX looks interesting…I didn't realize it forwarded X so it should work with all X applications. Looks like you need a software component on both sides, though. If I want to run more robust X applications remotely in the future I will probably look into using this.

Pretty much any remote desktop solution (X, NX, VNC, etc) will work with all X applications…

In NX's case, it sort of acts as an X accelerator. Part of the speedup is from compression, but most of the speedup is from eliminating round-trips and doing things asynchronously.

It should be noted, though, that all solutions will require software on both sides… Plain X forwarding will require X and an SSH daemon on the remote side, and an X server and SSH client on the client side.

I'm not a windows user, so I'm not sure, but does putty support the "-c" flag for ssh? It forces the data to be compressed between the client and the server. Looking at your ltrace values, and your tcpdumps, it appears that it wouldn't help, but it also wouldn't hurt to try if it is available…