Linked clone desktops slow on new connection

[danievera]

Hello.

I'm experiencing some strange (to me at least) behaviour when connecting to my virtual desktops (linked clones) over PCoIP.

Whenever I open a new connection (using Dell Wyse P25 zero clients, latest firmware), fast movements inside the desktop appear somewhat jerky/laggy. For instance, dragging around windows shows noticeable jerkiness.

However, if I keep dragging windows around for a while (like 10 seconds or so, I haven't actually timed it), the jerkiness disappears and fast movements become way more fluid than before (the way it's supposed to be).

As far as I could tell, once the desktop is "fluid", it will stay that way - UNLESS you disconnect the session and reopen it (same session, no logoff required) - then the jerkiness will return.

Does this ring a bell for anyone? To me it sounds like there's some kind of power management going on, but I've already disabled power management policies on every level I can think of: on the physical servers, in ESXi and the guest OS (Win 7 x64).

Some more details on my setup:

• ESXi 5.5.0, 1623387
• Horizon View 5.3
• HP Gen8 blade servers w/ 2 x 10 core Xeon E5 each
• VMs have 2 vCPU and 4 GB RAM, running Windows 7 Professional SP1
• 3D rendering enabled

Also, there's virtually no load on the ESXi hosts at the moment, as this is pretty much just a lab environment right now.

Please let me know if you need to know anything else.

Thanks!

Dan

[vcpguy]

Can you re-install your vmware tools and view agent. You need to follow this order.

[Rorus]

Hi Dan,

Sounds like the same thing we are getting - it is especially noticeable when moving Windows around.

We are running HP G8's on View 5.3, Win 7 SP1. I previously thought it may have been a storage issue, but we are now running all our linked clones (and replicas) off HP Storage IO accelerators, which have something stupid like 500,000 IOPs.

I found that in our case, if we create a full clone and a linked clone off the exact same template (and same snapshot), the linked clone will perform poorly with regards to visuals, and the full clone works wonderfully. This is why I suspect it is not a configuration thing, or any issue with agent/tools etc. Our full clones and linked clones also have the same PCoIP variables applied to them.

I previously raised a req with VMware, who essentially said something along the lines of "that's just how linked clones work...".

If you find anything that assists with improving the visual performance, please post back here. I'd love to improve the experience for our end users.

Thanks,

Rorus.

EDIT: Missed a word.

[Gaurav_Baghla]

Enable 3d Rendering on the Pool         

[danievera]

vcpguy wrote:

Can you re-install your vmware tools and view agent. You need to follow this order.

Tried it, nothing changed unfortunately.

I even created a new parent VM from scratch - same behaviour.

Rorus wrote:

Sounds like the same thing we are getting - it is especially noticeable when moving Windows around.

We are running HP G8's on View 5.3, Win 7 SP1. I previously thought it may have been a storage issue, but we are now running all our linked clones (and replicas) off HP Storage IO accelerators, which have something stupid like 500,000 IOPs.

I found that in our case, if we create a full clone and a linked clone off the exact same template (and same snapshot), the linked clone will perform poorly with regards to visuals, and the full clone works wonderfully. This is why I suspect it is not a configuration thing, or any issue with agent/tools etc. Our full clones and linked clones also have the same PCoIP variables applied to them.

I previously raised a req with VMware, who essentially said something along the lines of "that's just how linked clones work...".

Do rapid movements (e.g. moving windows around or opening/closing a lot of windows) change anything for you or does the lagginess stick?

For me, the responsiveness of the virtual desktops is actually pretty darn impressive once you get rid of the "initial lagginess".

Gaurav_Baghla wrote:

Enable 3d Rendering on the Pool   

3D rendering was already enabled on the pool(s).

I updated the OP accordingly.

[Rorus]

> Do rapid movements (e.g. moving windows around or opening/closing a lot of windows) change anything for you or does the lagginess stick?

While it seems to get better after initially dragging some windows around, there is still a noticeable lag. Especially when you compare it to a full clone.

[DKAllegroIT]

Hi, You haven't touched on the storage, is it local, SAN, whats the RAID config etc etc? Disk latency can always be an issue.

[TechMassey]

Are you able to duplicate this outside the P25 Zero Client? I would be curious if PCOIP on a PC on the same network exhibits the same issue. If you do duplicate it, I would then try enabling the ability to choose the display protocol and test with RDP from the desktop. If the issue doesn't occur, I would target two areas.

1. You may be using VMware GPO ADM template and it may be too restrictive, requiring to high a quality to get to lossless and thus the choppiness while it builds that cache.

2. I have found PCOIP to be, temperamental. I would check for packet loss as the primary culprit. Those jerky actions are not necessarily video related, they can literally mean the smooth motion playback is being dropped because PCOIP is UDP.

[danievera]

DKAllegroIT wrote:

Hi, You haven't touched on the storage, is it local, SAN, whats the RAID config etc etc? Disk latency can always be an issue.

It's a SAN, this particular LUN is 12 x 15k SAS in RAID10.

WarrenM01 wrote:

Are you able to duplicate this outside the P25 Zero Client? I would be curious if PCOIP on a PC on the same network exhibits the same issue. If you do duplicate it, I would then try enabling the ability to choose the display protocol and test with RDP from the desktop. If the issue doesn't occur, I would target two areas.

1. You may be using VMware GPO ADM template and it may be too restrictive, requiring to high a quality to get to lossless and thus the choppiness while it builds that cache.

2. I have found PCOIP to be, temperamental. I would check for packet loss as the primary culprit. Those jerky actions are not necessarily video related, they can literally mean the smooth motion playback is being dropped because PCOIP is UDP.

I tried the (latest) Windows View client and I'm getting a similar effect - although performance seems to be better with the zero clients (just seems a little smoother overall).

I guess you are referring to the PCoIP ADM template? The only settings I've made are: minimum image qualitiy: 40, maximum image quality: 80, build to lossless: disabled.

It doesn't make any visible difference to using the default settings.

What do you suggest?

Thanks!

[TechMassey]

Overall it still sounds like its PCOIP specific if you haven't identified any other bottlenecks. Have you tried RDP based on my previous post? If you still have issues, you might want to demo a VDI monitoring package like Liquidware Labs Stratusphere.

[danievera]

WarrenM01 wrote:

Overall it still sounds like its PCOIP specific if you haven't identified any other bottlenecks. Have you tried RDP based on my previous post? If you still have issues, you might want to demo a VDI monitoring package like Liquidware Labs Stratusphere.

RDP doesn't seem to be affected by it, but it's hard to tell, as RDP doesn't allow for very smooth movement in the first place.

I also think it's probably PCoIP specific - are there any settings I could tweak/play with?

[TechMassey]

If PCOIP was the issue, the difference between it and RDP should be very noticeable. Also, RDP on the LAN can be very fast, even with moving windows but typically not videos. RDP is TCP based, so it will make sure that each click is accurate while PCOIP will just not show or say anything if it doesn't see the click. If your having trouble telling the difference between the two in terms of performance, then both may affected by something else on your network. I would look at latency/packet loss/bandwidth.

[danievera]

I had my network guy look over the network and we couldn't find any issues.

So this still looks like a PCoIP issue to me. Anything else I can try?