X-Win32 Knowledge Base   >   How do I speed up X-Win32 sessions

Search


About StarNet

StarNet Communications has been a leading developer of X Windows solutions since 1989. After establishing X-Win32 as the de facto standard in the higher education market during the early to mid-1990s -- 150 unlimited Campus Site Licenses worldwide -- X-Win32 has become of one the top three PC X servers in the government and commercial sectors as well.

Unlike its major rivals, Exceed (Hummingbird) and Reflection-X (WRQ/Attachmate), X-Win32 offers a highly focused PC X server that offers superior performance and productivity features, stability, ease of use and low cost (40% or better in most cases).

StarNet also delivers unequaled customer support. Our state-of-the-art engineering infrastructure allows us to fix problems and make a new release available quickly (overnight in many cases). As our testimonials page shows, StarNet customers consistently rate their X-Win32 experience as the best in the industry.




How do I speed up X-Win32 sessions

The speed of X-Win32 sessions is highly dependent on the latency and throughput of your network. However, there are things that can be done to make your applications more usable on slow network connections or to make your X-Win32 users use less bandwidth on your network.

There are also a few bugs that have been fixed in X-Win32 8 that sometimes resulted in slow X-Win32 sessions in earlier versions. You may want to consider upgrading to X-Win32 8 today!

General reasons for slowness

  • Your applications are using anti-aliased text and graphics
    • Solution: Upgrade to X-Win32 8, which now features the Render Extension. Emulation of anti-aliased text in X-Win32 7.1 and prior caused many network round-trips, thus slowing down your applications; the Render Extension in X-Win32 8 and later eliminates these round trips, giving you great looking graphics at an incredible speed.
    • Switching between application windows in Multiple Window Mode is slow
    • Solution: Upgrade to X-Win32 8, which features Window Caching by default. This Window Caching makes minimizing/restoring, moving, swapping, and other window operations instantaneous and these operations cause very little network traffic.
    • Switching between application windows in Single Window Mode (e.g. Xdmcp sessions) is slow
  • Solution: Change the Backing Store option in X-Config to Always On, then restart X-Win32. Switching between windows should now be much faster. Note: This only applies to X-Win32 8 and later, as X-Win32 7.1 and earlier had a bug that caused 100% CPU usage when Backing Store was enabled.

    Specific reasons for slowness in StarNetSSH sessions

    StarNetSSH sessions can be slow for a few reasons:

    • X-Win32 7.1 and earlier had slowness issues with certain SSH servers (often exhibitited by logging in to a host taking 30 seconds to a minute).
    • Solution: Upgrade to X-Win32 8, which features an all new StarNetSSH implementation that has fixed these slowness issues.
    • X-Win32 7.1 and earlier are not taking advantage of your dual core or multiple CPUs
    • Solution: Upgrade to X-Win32 8, which has StarNetSSH as a separate module that can utilize your additional CPUs for each StarNetSSH session.
    • The remote CPU is heavily loaded, thus the encryption/decryption processing is causing a significant delay
    • Solution: Increase the CPU power of the remote host or partition your users or services onto different hosts
    • Compression is disabled and your applications are across a slow or high latency network
    • Solution: Enable compression in your StarNetsSSH session.
    • Compression is enabled but your applications are on the local network
    • Solution: In this case, compression is of little advantage and may actually be slower than not using compression due to the delay and CPU usage from compressing and decompressing the data. Therefore, you may want to turn compression off. NOTE: X-Win32 8 ships with compression on by default for StarNetSSH sessions, while X-Win32 7.1 and earlier shipped with compression off by default for StarNetSSH sessions.
    • Encryption is too heavy of a load for your system
  • Solution: Although not advised, you can bypass the encryption by changing your StarNetSSH session command from xterm -ls to xterm -ls -display @DISPLAY@ (or xterm -ls -display $DISPLAY prior to X-Win32 8). This will send all of your data in plain text, just like an rexec, rsh, or Xdmcp session.

    Specific reasons for slowness in rexec and rsh sessions

    • There is a 30 second to 2 minute delay on starting your rexec or rsh session before your application is started.
  • Solution: This is a bug in how rexec and rsh sessions are authenticated on the remote host when there is a firewall between the remote host and X-Win32. The remote host is trying to open an identd (identification service) connection to your X-Win32 machine in order to log the user name that is trying to connect to rexecd or rshd; when a firewall is enabled the connection attempt must timeout after 30 seconds to 2 minutes instead of immediately receiving a failure message. You can confirm that this is the problem by temporarily disabling the firewall software on your Windows machine; the ultimate solution is to change the configuration of inetd or xinetd on your remote UNIX or Linux host so that it no longer attempts to make an identd to your X-Win32 machine.

    Specific reasons for slowness in Xdmcp sessions

    • Xdmcp sessions take a long time to start and are sluggish
    • Solution: Switch to a rexec, rsh, or StarNetSSH session. Xdmcp sessions are slow because they run around 20 applications on startup (particularly for KDE and Gnome desktop sessions), they draw a desktop wallpaper, and they can cause a remote screen saver to be displayed when the session is inactive. All of these operations take a lot of network bandwidth and round trips. It is much lighter weight to start an xterm through another session type, then to start only the applications that you need from this xterm (e.g. mozilla, oowrite, kword, cadence, etc.)
    • Xdmcp sessions take a long time to logout of Gnome (particulary on Red Hat Linux or RHEL) and seem to freeze when Logout is selected from the Gnome Menu
    • Solution: This is due to a bug in how Gnome interoperates with firewall software. If you disable your firewall software on your X-Win32 machine, you will notice that Gnome no longer freezes when you select Logout. To permanently solve this problem, you must open TCP port 35091 in your firewall.
    • Xdmcp sessions in X-Win32 7.1 and earlier take 100% of the CPU, making them sluggish
  • Solution: Upgrade to X-Win32 8 or later, as this was a bug in X-Win32 7.1 and earlier that happened when Backing Store was set to Always On or when PseudoColor Mode was enabled. Alternatively, you can turn off both of these options in X-Win32 7.1 and earlier to avoid the 100% CPU problem.

    Category:FAQ
    Category:Sessions



How Can We Improve This KB Article?

Please rate the quality of this article: Excellent Good Fair Poor

Did this article answer your question? If not, we'd like to hear more about it:

Do you need additional assistance? If so, enter your email address:

Articles are periodically updated based on your feedback. If you enter an email address, then you will be given the opportunity to open a case, for which you will receive a response within 2 business days.