Xmanager is so slow if protocal is SSH [12]

When I use XDMCP protocal and let the remote Unix box connect to my X server, it's very fast, almost no delay.
But when I use Xstart to start gnome-session using SSH protocal, it seems that the data transfer rate is very slow so the X-window responses in a great delay, for example, if I start text editor it will be about 10 seconds for me to see the editor window. But I tried transfer file through SSH and the rate reaches to 150K/s. So I'm wondering if there are any ways to speed up the response while using SSH?

The problem may happen when X applications can't convert the hostname of Linux
to IP address. When you connect to Linux with SSH, the display variable (DISPLAY)
is configured such as:

$ echo $DISPLAY
DISPLAY=hostname:10.0

If your name server don't know how to convert the hostname to IP address or
the name server responds slowly, you have such a problem.

I suggest you add an entry into the /etc/hosts file of Linux. It will improve
the response time and override any errors of the name server.

Hope to solve the problem.

----
Technical Support

I'm not sure if I understood you completely, so let me describe in more detail. My Windows box is in private network(ip 192.168.*) and the Linux(RedHat 9.0) is in public network with a public ip(210.34.18.2), then the windows box start the GNOME through SSH. The hostname of the Linux box is 'manland' and domain name is manland.xmedu.com, and manland.xmedu.com -> 210.34.18.2, now the hosts file under /etc is with the content:
127.0.0.1 localhost.localdomain localhost
210.34.18.2 manland manland.xmedu.com

and if I run command like 'ping manland' or ping 'manland.xmedu.com' on the Linux box it pings successfully.

Now the response between Xmanager and the GNOME still delays unbearablely.

Could you give me further advise to overcome this?

BTW, I tried to SSH to the Linux box using putty and SecureCRT, and under both curcirmstances the $DISPLAY is not defined.

I'm finding that I have the same performance problems. When I invoke X applications through SSH, screen refreshes are unbelievably slow. It's definitely not anything to do with hostnames.

I also have VMWare installed on my Windows machine. When I fire up a Linux session within VMWare, and use it to SSH to my usual host, screen refreshes in X apps are virtually instantaneous.

Now, in this situation, we have a virtual PC, running against a virtualized network interface, and it's getting better performance than the Xmanager direct session. And, remember, it's ultimately using the same physical hardware in both cases and resolving hostnames in the same way.

Thanks for your feedback.

There may be a problem in the SSH module of Xstart. Please try our SSH client, Xshell to get an xterm or other X applications. You can download Xshell at:

/download/download.html

The Xshell client automatically launch Xmanager when an X application is invoked through Xshell.

We would appreciate your feedback.

----
Technical Support

Apps launched from Xshell run orders of magnitude faster than from Xstart. I hope that 2.0 release of Xmanager is due soon!

I still experience this situation.

SSH sessions via XSTART = slow with Xmanager 2.0
SSH sessions via Xshell->Xmanager = Very fast.

The 2.0 upgrade hasn't seemed to fix the issue. I have registered Xmanager, but wonder if I really have to register the Xshell application just to get Xmanager to respond at the appropriate speed.

Is SSH via Xshell the solution to slowness issues, or will the SSH implementation of Xmanager/Xstart be fixed?

Thanks.

This problem may occur when the application requires terminal to be allocated before lauching it.

Please try selecting the "Allocate a pseudo terminal before executing the command" option. To do this, please follow the instruction below:

1. Start Xstart.
2. Select a session that you are experiencing problem with.
3. Click Setup.
Result: SSH Protocol Setup dialog box opens up.
4. Click the Options tab.

If you are using broadband connection or if your PC and the remote host are in a same network, skip step 5.
5. Select Compress network data.

6. Select Allocate a pseudo terminal before executing the command.
7. Click OK.
8. Start the session.

If your problem persists, please send us the following information:

1. Vendor/version of the remote host.
2. Name/version of the application.

Please let us know if we can be of further assistance.

Thank you. That resolved the problem nicely. The compression seemed to be key, even though I'm on broadband, with an 8 Mbps connection at one end, and a 100Mbps fiber optic connection at the other end. Without the compression there was no difference in speed. With the compression turned on I now see the same speeds as with Xshell, maybe even faster.

This is also still a problem in XManager3. Running applications from SSH requires launching from the XShell to get decent performance. Some applications essentially ground to a halt with XStart. Xrcmd.exe used 100% of a cpu core. Compression and allocating a pseudo-terminal had no effect for me.

This seems to be a serious long-standing bug. My company will probably not be purchasing XManager licenses due to this performance issue.

This problem is lasting for very long time because we were not able to duplicate the problem. It seems the problem occurs only under certain circumstances. We would appreciate if you can share with us your system settings so that we can try to duplicate the problem one more time.

Please answer the following question:

1. Do the X applications halt right away or is there any specific time frame until they halt.

2. Please enable the "Show reply message" option on Xstart and start the application. Copy all messages from the Xrcmd: Reply messages dialog box and send it to us.

We appreciate your cooperation and will try our best to resolve this problem.


---
Technical Support

The application will usually halt within the first 30 seconds of starting. After turining on "show reply messages", it seems the problem happens when the remote application is printing numerous messages to stdout or stderr.

For example, the attached "log.txt" shows the Gnome system monitor spitting out countless warnings in a just a few seconds. The system monitor in XManager's window freezes while the "Reply Messages" windows continues to fill-up with warnings.

In another the application, rather than freezing, the application slows down on the remote machine to 5% cpu usage in 4 second bursts that seem to be timed with XManager network activity.

Thank you for your cooperation. We have successfully duplicated the problem and the fix will be included in the January release.

Please check back again for any updates.


---
Technical Support