VMware Horizon Community
curttc
Contributor
Contributor

Horizon Blast / Mouse issues.

I have been dealing with a specific problem ever since deploying Horizon in our environment that I now believe through over a month of troubleshooting is related to the Blast protocol.

For some context, we are running the following in our environment:

Non-Persistent VM's (4 CPU, 4GB Memory, Windows 10 v.1809)

Dell Wyse 3040 ThinOS Clients

Latest version of Horizon Agent

Latest version of VM Tools on Golden Image

Nvidia M10 GRID GPU (2GB profile)

Each user has 2 x 1080p monitors

We are also running all flash storage (Pure Arrays) over a 10Gbps dedicated iSCSi network, so throughput really isn't an issue.

Initially when rolling out for testing, users would report that randomly (no consistent time frame), they would experience the mouse jumping in their session. Whenever they would try to move windows around on the desktop, the mouse pointer would disappear, and the window would stop moving for a couple of seconds at a time, then continue moving again. The would also see this behavior when just moving the mouse inside of any open window as well. They would move the mouse back and forth, the cursor would disappear and jump all over the place inside the window. The only fix to the solution is to bounce the power to the thin client, and functionality is restored until the problem occurs again. The kicker is, this issue has never occurred if users connect to their session via the Horizon agent on a regular machine (thick client) or the HTML view. It only happens with the Wyse 3040 ThinOS clients.

When I first encountered the problem and discovered that it was consistent, I believed that it could be related to the resources allocated to the VM's. I added more CPUs, more memory, tried different desktop pools, rebuilt the golden image, etc. and the problem still persisted. Eventually, I started having users call me when the issue would start happening and monitor their session via vSphere to see if there were any performance spikes. CPU was fine, memory was fine, network and disk, all fine. I also opened a ticket with VMware in which they requested debug level logs (they were of little help and extremely slow to respond. Ended up closing the ticket, but plan on opening another.)

As of recent, I started to narrow it down a bit more. My original assumption was that when the user experienced the issue, that it was system-wide, meaning the mouse would jump all over the place regardless of what they had open at the time or what they were doing. As of yesterday, I found that this is not the case. The problem ONLY happens when the mouse is moved into an open window. If they close out of all windows or simply move the mouse out of a window onto the normal desktop, the mouse moves and functions properly. What I also noticed is that if I Teamviewer into the users session while the problem is occurring and move the cursor into a window or drag a window, the problem does not occur from my view, but from the view of the Wyse Client, the stuttering is there. Same for vice versa, if the user experiencing the issue begins to move the mouse or a window, they see the stuttering from their view, but from the Teamviewer connection, I see normal movement.

Looking at some of the blast logs when the problem occurs, I'm seeing things like this:

2020-03-02 15:28:43.761-0500 [WARN ] 0x072c bora::Warning: VVC: Queue times would make rtt go negative; rtt = 67332us,  queueTimeLocal = 66429us,  queueTimeRemote = 1000us)

From my understanding of blast and how it utilizes h.264 encoding, this would make sense to see queue times building up and causing the delay that I'm seeing. The strange thing is, I'm not sure what to blame. Could it be more related to the ThinClient and ThinOS seeing as how a reboot of the ThinClient temporarily fixes the problem, or is there something network related? I have also updated the Wyse clients to the latest firmware version and have checked for errors on the switchport they are plugged into (none are found). We have some newer Wyse clients coming in soon that we have ordered for testing (better hardware), but I'm not certain that will resolve the issue, seeing as how other people have reported the Wyse 3040 ThinOS models to work just fine in their environments.It's also worth noting that I have also tried connecting users with the PCOIP protocol and get the exact same behavior.

Has anyone ever experienced anything like this? I'm closer than I was a month or so ago in resolving this issue, but I still don't feel like I have enough conclusive evidence as to what is to blame for this phantom behavior.

Reply
0 Kudos
3 Replies
jonathanjabez
Hot Shot
Hot Shot

Hi,

Check the below Dell article. The issue is more to do with the ThinOS of Dell WySe 3040 Thin Client. Dell Wyse ThinOS Version 8.6 and ThinOS Lite 2.6 Operating System Release Notes

Reply
0 Kudos
curttc
Contributor
Contributor

Hi,

Thanks for the response. I went ahead and made those changes per the article, but after rebooting the 3040, I can see the INI settings have been applied, but now I'm seeing some really strange behavior. The mouse cursor now looks like this:

IMG_3081.jpg

I also notice ever since making the change that the mouse seems to stop at certain points randomly even if I continue to move it in one direction, almost as if the relative mouse feature is not playing with the resolution correctly. Is this normal behavior or does anything else need configured in conjunction with the enable relative mouse feature?

Reply
0 Kudos
jonathanjabez
Hot Shot
Hot Shot

Hi,

I would suggest, you can revert the changes made related to mouse setting and then raise a support ticket with Dell Wyse Support team to work on this issue.

/Jon

Reply
0 Kudos