VMware View 3.1 & WYSE V10L - Display Refresh Issue

[gqstyles55]

Hi everyone,

We are just in the middle of a VMware View 3;1 deployment using the new WYSE V10L thin clients. We seem to be having a bit of an issue with the display refresh rate. Let me explain better (and just to preface, the back-end VMware environment is running VI 3.5 on 5 brand new HP Blades and a NetApp SAN. The entire network is running Gigabit as well)...

I'm not sure if this is simply a limitation of the RDP protocol, but the few of us working on the project need some verification. Basically, a session running on one of these WYSE terminals seems like the display is choppy and the screen refresh rate is poor. Just regular browsing on the Internet (scrolling up and down on a webpage) seems to be pretty choppy as well. Just to give you a comparison, if this were a regular PC, I'd say it didn't have the correct display driver installed. Even just minimizing windows seem to lag and the display seems to have trouble drawing the images to the session. You would think that we were running in a remote office WAN , hundreds of miles away. But were just on a local LAN (with no sign of any network contention/latency that we can see).

I hope I explained this well enough for you guys to understand. We were just expecting the performance to be a little bit better from a display point of view. But maybe we're asking too much through a regular RDP session. I'm hoping someone has run into a similar issue and can provide some assistance (or tell us that this is the best we can expect). Obviously it's hard to really see what I mean without seeing the issue with your own eyes. Any help would be appreciated.

Thanks, guys.

gqstyles55

[arjanhs]

Try increasing the cashe size on the thinclient, got some simmilar problems with some Wyse v90l models

[gqstyles55]

Hi arjanhs, thanks for taking the time to read and reply to my question. By increasing the cache size on the thin client, do you mean the physical RAM installed?

[hmartin]

Hi gqstyles55,

From your description, I think it's fair to say that your expectations are fine, but there's a problem with the configuration. Here are a few questions / thoughts:

Try bypassing the VMware View components by connecting directly to one of the guests by using Remote Desktop. This will greatly narrow down your "search area. How does it perform then? If it's still bad, you've probably eliminated all of the View components from your list of possible problems. If it's good, start looking at View. Are you tunneling RDP through the View server?

What is the guest OS (XP Service Pack ?)

Is VMware Tools installed in the guests?

Did you configure the V10L's Ethernet adapter or did you leave it at Auto-Negotiate? That's OK, but make sure that the V10L's configuration matches that of the network switch port. Both should be Auto or both should be set to 100 Full Duplex. You specifically mentioned Gigabit, but I'm fairly sure the V10L's don't have gigabit interfaces. Check the switch port's status (e.g. if everything is set to Auto, Cisco switches will tell you at what speed and duplex setting they negotiated). For example, they could have negotiated to 10 half! To be sure, try setting both the V10L and network switch port to 100 Full Duplex.

When viewing web sites, try to avoid pages with Flash. They will really impact the entire RDP session.

What display resolution did you set on the V10L?

In Windows, what are the color settings (15 bit, 16, bit, etc.)?

Hope that helps.

[gqstyles55]

Hi hmartin,

Thanks for your reply. Here are the answers to your questions:

Try bypassing the VMware View components by connecting directly to one of the guests by using Remote Desktop. This will greatly narrow down your "search area. How does it perform then? If it's still bad, you've probably eliminated all of the View components from your list of possible problems. If it's good, start looking at View. Are you tunneling RDP through the View server?

I have actually tried a direct RDP to one of the guests, thus removing the WYSE terminal and View components. We have a noticed an increase in the overall performace of the session running this way. So that may be telling me something. As far as the View setup, is it possible for you to advise what the best practice is for the server setup in View? We have two View servers and right now, the option "Direct connection to desktop" is not enabled. However, it seems that when we enable this setting, it kills the access from the remote URL we have configured.

What is the guest OS (XP Service Pack ?)

Windows XP SP3

Is VMware Tools installed in the guests?

Yes

Did you configure the V10L's Ethernet adapter or did you leave it at Auto-Negotiate? That's OK, but make sure that the V10L's configuration matches that of the network switch port. Both should be Auto or both should be set to 100 Full Duplex. You specifically mentioned Gigabit, but I'm fairly sure the V10L's don't have gigabit interfaces. Check the switch port's status (e.g. if everything is set to Auto, Cisco switches will tell you at what speed and duplex setting they negotiated). For example, they could have negotiated to 10 half! To be sure, try setting both the V10L and network switch port to 100 Full Duplex.

I belive you are correct. The V10L's are only 100 MB. I also am pretty sure all the networking side of things on the switches, etc. have been hard-coded to gigabit.

When viewing web sites, try to avoid pages with Flash. They will really impact the entire RDP session.

I agree, running anything with flash without any third-party RDP acceleration will be ordinary at best.

What display resolution did you set on the V10L?

1280 by 1024

In Windows, what are the color settings (15 bit, 16, bit, etc.)?

24-bit

[hmartin]

If the switches are in fact hard-coded to gigabit, that may be part of the issue. As a test, configure a switch port to 100 Mbit Full Duplex and confirm that the V10L on that port is also configured to 100 Mbit Full Duplex (neither should be set to Auto-Negotiate). I admit that since straight RDP works better, it may not be a major factor, but I'll bet if you look at the switch port stats, you'll see a lot of errors, retries, etc.

As for View Manager, you mentioned a remote URL. Are the V10Ls, ESX servers, etc. on the same Ethernet network as the View Manager server? Or is there a WAN involved? If not, how does enabling "Direct connection to desktop" affect performance of the V10L? If it's better, then perhaps you can deploy a View Manager server for just the remote systems and a separate View Manager server for the LAN-based systems.

[gqstyles55]

Hi hmartin,

We only have one office. So all sessions are running over the LAN. We do have it setup for users to access their session remotely via the View portal (but I'm not concered as much with remote access, only internal sessions on the LAN).

Let me give you a quick run-down of our View servers setup...We have one Security Server setup that is configured for the remote access that has the external DNS entry for remote access (I assume the security server is only for remote access authentication - I must admit, I wasn't the engineer who set this up so the View stuff is realatively new to me). We then have two View servers in a load-balanced setup. Neither of these servers have the "Direct connection to desktop" options enabled. And only one of these servers has the same external URL as the security server.

I guess what really need to understand is what is the best practice setup for the view servers given the environment we have? Hopefully you can shed some light on this for me.

Cheers.

[hmartin]

I haven't yet set up a security server, but the fact that the two other servers are load-balanced but configured differently would be a concern to me (only one having the external URL). I would suggest testing without (or around) the load-balanced configuration. Assuming the two load-balanced View servers have at least two IP addresses (the virtual load-balanced address and a direct IP address), you should be able to configure one of the V10Ls to use the direct IP address instead of the load-balanced address. That would allow you to test this configuration without affecting anyone. If so, start with the View server that does not have the external URL configuration. If all works well even with "Direct connection to desktop" disabled, then reconfigure your V10L to use the other server. Is performance still good? If so, then look at the load-balanced configuration.

If the security server requires a View server behind it with the external URL configured and "Direct connection..." disabled, then, in my opinion, you'll probably want to break the cluster you have now and either configure two separate clusters (one for internal users and one for the security server). On the cluster for internal users, enable "Direct connection..." for best performance (unless there are some security concerns.

[gqstyles55]

Hi hmartin, I like your idea about connecting directly to one of the View servers via it's direct IP. This will hopefully eliminate the View server and load balancing setup as a possible issue. Thanks for your suggestions. I will give this a try on Monday and let you know how I go. I some you some points for all your help :8}.

[hmartin]

The updated View Manager Admin Guide (PDF) has some good information about possible Security server configurations. See pp. 30-33. They seem to support what we've discussed. Good luck.

[hmartin · Accepted solution]

gqstyles55, any update?

[gqstyles55]

Hi hmartin,

Sorry for the delayed response. It's been a crazy week at the office . Thanks again for the link to the updated View Admin guide. I had a read through the section you mentioned and it helped me understand the possible scenarios for server setups in the View environment. Unfortunately, I'm still not much further ahead then I was last week, even after trying to connect directly to one of the View servers. One thing I haven't been able to confirm (even after reading through the admin guide) is the proper setup for the View servers in our environment and what affect the "Connect directly to desktop" option has on users coming in externally through the security server. Even though I don't believe this will have anything to do with my overall issue, which is the display/screen refresh issue (mostly when scrolling on webpages or Office documents). I'm hoping to get some answers tomorrow.

I'll let you know if I get anywhere after tomorrow.

Thanks again...

[Lupem]

I have the same issue. Also have the V10L models. Get the latest firmware for the wyse. What version you have. Contact me if you need the firmware. You will then be forced to setup a FTP server to load the VL10_WNOS.ini file into the wyse devices when they load. Every Single time. You also need a FTP server to install the firmware. They also sell the WYSE TCX licensing for the multimedia to correct some of the choppyness. Which they don't tell you unless you buy their support.

Enter these items in the INI. These are also required if you use WYSE devices.

TCXLicense=License keys go here

DesktopColorDepth=32

sessionconfig=rdp defaultcolor=2

Also, VMs can only do 16 frames per second. Videos are an 20+ fps. DVD and 760p videos will always have a choppy feeling. I switched to the Dell FX160s because of this issue. i have an external USB DVD player and just runn the videos in the terminal and not with in the VMs.

Also, the support for the WYSE devices is from israel. When communicating with them, make sure you have ARAB language interpretations enabled in you email client. I hate their support.

here are some settings wyse gave me for the VMs.. This is required for any VM from any Terminal.

Steps 1

Remote Desktop server on Windows XP only support up to 24-bit video through a RDP session. However, by default it only runs in 16-bit. It is, however possible to change it by tweaking a group policy setting in Windows XP. To do this:

1. Open up the Group Policy editor, by going Start --> Run and type in MMC.

2. Add the Group Policy snap-in by going File --> Add/Remove Snap-in --> Add --> Group Policy Object Editor --> Add --> Finish (Local Machine) --> Close --> Ok.

3. Now navigate in the Group Policy Object Editor from Local Computer Policy --> Computer Configuration --> Administrative Templates --> Widnows Components --> Terminal Services and double-click on the 'Limit maximum Color Depth' object.

4. By default the policy is disabled and sets you to 16-bit color. Click on 'Enable' and choose either 'Client Compatible' or 24-bit to enable the highest resolution of 24-bit (True Color) to display via Remote Desktop. Options include 8-bit, 15-bit, 16-bit, and 24-bit.

[Lupem]

You also need these settings also

• a. you are required to install remote desktop 6.1 from microsoft. If you have SP3. No need to install.

• Regestry settings. b. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

• i. Change the color depth to 4

[EXPRESS]

Hi qqstyles55,

I too have seen and have experienced this, what I had noticed what the problem for us was the firmware, some work better than others. Which one are you using?

Thank you,

Express

[Lupem]

Express is correct. Firmware is a Big issue with Wyse devices. i sometimes wonder who their test subjects are before they release firmware upgrades.

[gqstyles55]

Hi everyone,

Thanks to all of you for your suggestions. We have actually got the user experience on the Wyse terminals to a point that is acceptable. I should have updated and closed this call about a week ago, but I forgot. It looks like what had the most impact was lowering the colour depth to 15-bit via GPO. We did make sure the latest firmware for the Wyse terminals was pushed out to all terminals. There were also a few other GPO tweaks we did, but for the most part, lowering the colour depth seems to have done the trick.

Thanks again for everyone's assistance.

gqstyles