logo
1x1 1x1 1x1 1x1 1x1 1x1
1x1
 

How to improve VMware View video performance

ImproveDuring the last weeks we’ve been busy implementing a large VMware View deployment for one customer and planning an even larger VMware View deployment for another customer. At the first site we ran into some video performance issues which we definitely want to avoid during the second project.

In our quest to solve and avoid the video performance issues we ran into a number of ways to improve the video performance in VMware View that I would like to share.

First of all, we used the information below from the VMware Architecture Planning Guide:

480p-formatted video You can play video at 480p or lower at native resolutions when the View desktop has a single virtual CPU. If the operating system is Windows 7 and you want to play the video in high-definition Flash or in full screen mode, the desktop requires a dual virtual CPU.

720p-formatted video You can play video at 720p at native resolutions if the View desktop has a dual virtual CPU. Performance might be affected if you play videos at 720p in high definition or in full screen mode.

1080p-formatted video If the View desktop has a dual virtual CPU, you can play 1080p formatted video, although the media player might need to be adjusted to a smaller window size.

3D If you plan to use 3D applications such as Windows Aero themes or Google Earth, the Windows 7 View desktop must have virtual hardware version 8 and turn on the pool setting called Windows 7 3D Rendering. Up to 2 monitors are supported, and the maximum screen resolution is 1920 x 1200. This non-hardware accelerated graphics feature enables you to run DirectX 9 and OpenGL 2.1 applications without requiring a physical graphics processing unit.

These are the settings we used to size the first solution, so we use a Windows 7 desktop image with dual vCPU, 2GB memory, a VMXNET3 adapter and hardware version 8.

Update 03-2014: We recently found out that with the recent improvements in vSphere 5.5 and Horizon View 5.3 we can now offer full screen 720p video with only 1 vCPU VDI virtual machines. VMware has not yet updated their documentation but a VMware employee confirmed that updates in eg. the code of the VMware SVGA graphics driver resulted in this improvement.

This is good for playing 720p in native video resolution but when scaling to full screen this setup does not run smoothly.

Note how it says “native resolutions“, plural. In this case, 720p only defines the aspect ration of 16:9 and 720 horizontal scan lines. In this case native resolution means, the resolution in which a video is presented to you by default, with no up- or down-scaling applied. So it does not define 1280 × 720 video resolution.

 

Modify Fast Send Datagram Threshold

For desktop VMs using VMXnet3 NICs, you can significantly improve the peak video playback performance of your View desktop. The VMXNET3 adapter is a paravirtualized NIC designed for performance that, as of vSphere 5, supports interrupt coalescing. Virtual interrupt coalescing is similar to a physical NICs interrupt moderation and is useful in improving CPU efficiency for high throughput workloads. Unfortunately, out-of-the-box, Windows does not benefit from interrupt coalescing in many scenarios (those sending packets larger than 1024-bytes), because after sending a packet, Windows waits for a completion interrupt to be delivered before sending the next packet.

By setting FastSendDatagramThreshold to the Microsoft recommended value of 1500 bytes you instruct Windows not to wait for the completion interrupt even when sending larger packets. So modify the following registry setting to the value:

HKLM\System\CurrentControlSet\Services\Afd\Parameters\FastSendDatagramThreshold to 1500

This allows VMware View and PCoIP to benefit from interrupt coalescing which reduces CPU load and improves network throughput for PCoIP. This translates into significantly improved video playback performance of up to 1.4 times when running full-screen videos at 1080p resolution on a 2vCPU desktop.

PCoIP

 

Configure PCoIP image quality levels

With View 5 VMware has released a few VMware View GPO’s that can be used to modify the default behaviour of the PCoIP protocol. Many View customers use this to turn down the bandwidth PCoIP uses in low bandwidth situations. This lowers the frame rate, limits the bandwidth and thereby it changes the image quality. But you can also use it the other way around and allow for better video performance.

PColPMaxLinkRate GPO
This GPO can be used to set the desired maximum PCoIP session bandwidth in kilobits per second.
(example: 1000 = 1000Kbps = 1Mbps). The default value is 1Gbps (1.000.000Kbps), 0 = no bandwidth constraints.

When you are in a LAN environment and bandwidth is not an issue, try setting the PColPMaxLinkRate to ‘0’ to improve the video performance.

PColPlmagingMinimumlmageQuality GPO
This GPO can be used to adjust the minimum image quality. Range is a value between 30-100, the default value is 50. When  you set a lower image quality (lower value) the result is a higher frame rate for smooth motion but with lower image quality. When you set a higher image quality (higher value) the result is crisp imaging but with less smooth image motion.

To improve the video performance try lowering the PColPlmagingMinimumlmageQuality value.

PColPlmagingMaximumlnitiallmageQualitv GPO
This GPO can be used to adjust the maximum image quality. Range is a value between 30-100, the default value is 90. When  you set a higher value, the result is a higher initial image quality, with larger peaks in bandwidth during large screen changes. When you set a lower value, the result is a lower initial image quality, with smaller peaks in bandwidth during large screen changes.

When you suspect that bandwidth is an issue, for instance on WiFi connections, try lowering the PColPlmagingMaximumlnitiallmageQualitv value to improve the video performance.

 

These setting are the default VMware View GPO settings to adjust PCoIP behaviour but I also found a PCoIP setting hidden in the registry.

PCoIP.maximum_frame_rate
This setting can be used to set the maximum frame rate. The default value is 30 frames per second. When you set a higher value, the result is a higher frame rate and smooth display imaging motion but with possible increased average network bandwidth. When you set a lower value, the result is a lower frame rate with a lower average network bandwidth but with less smooth image motion.

To improve video performance, create the registry key below (REG_DWORD) and try some higher values. Setting in frames per second/Hz (example: 8, 12 or 15 fps).

HKEYLOCAL_MACHINE\SOFTWARE\Policies\Teradici\PC0IP\pcoip_admin\pcoip.maximum_frame_rate

 

Handle with care
All these settings above can improve the video performance dramatically but as a result it consumes more bandwidth. My advice would be to use Active Directory, logon scripts and/or workspace managers like RES to apply these settings to only the desktops that need better quality video performance and are on a LAN with the bandwidth needed. Don’t use it for all VDI desktops unless everyone needs better quality video performance.

 

PCoIP settings

 

 

Multi-Media Redirection

If all this fails you can always reside to old fashioned Multi-Media Redirection (MMR) and use the local processing power to render the video on the client side, but this has some caveats.

Multimedia redirection (MMR) delivers the multimedia stream directly to client computers by using a virtual channel. With MMR, the multimedia stream is processed, that is, encoded and decoded, on the client system. Local hardware formats and plays media content, thereby offloading the demand on the ESX/ESXi host.

The problem is that there is only limited support. The MMR feature supports the media file formats that the client system supports, because local decoders must exist on the client. File formats include MPEG2-1, MPEG-2, MPEG-4 Part 2; WMV 7, 8, and 9; WMA; AVI; ACE; MP3; and WAV, among others.

This feature has the following limitations:

  • For best quality, use Windows Media Player 10 or later, and install it on both the local computer, or client access device, and the View desktop.
  • The Wyse MMR port, which is 9427 by default, must be added as a firewall exception in the View desktop.
  • MMR is not supported with PCoIP on Windows 7 clients or virtual desktops.

Windows 7 clients and Windows 7 View desktops do not support MMR. For Windows 7 clients agents, use Windows media redirection, included with RDP 7. For  this to work you need to use Windows Media Player 10 or later, and install it on both the local computer, or client access device, and the View desktop.

About

Erik Scholten is the founder of VMGuru.nl and works for Imtech ICT as a Solution Architect creating the most ingenious virtual infrastructures. He has over 16 years experience as a system engineer and consultant and now he specializes in virtualization. His current job includes selling, presenting, designing and developing virtual infrastructures for some major companies in the Netherlands. Erik is a certified VMware VCP (3, 4, 5), VCP Desktop (5), VSP (3, 4, 5) and VTSP (3, 4, 5). In 2009, 2010, 2011, 2012, 2013 and 2014 VMware awarded him the vExpert award for his virtualization community efforts.

  • Pingback: How to improve VMware View video performance at That's my View

  • Pingback: обзор блогов по виртуализации | vMind.ru

  • David P.

    Hi,
    Thank you for the tips. It’s really better now with 2 vCPU into my vSphere 4 !
    But now in vSphere v5.5, I can choose to have 1 or two vCPU, or instead 1 vCPU with 2 cores.
    What is the best choice in your opinion?

    • http://www.vmguru.nl Erik Scholten

      Apart from VDI or server virtualization, this choice depends on two things, performance and licensing.

      First performance, When specifying the number of virtual sockets and the number of cores per virtual socket, VMware’s best pratice recommends to leave this at the default value of 1 core per socket. So, the number of virtual sockets is therefore equal to the number of vCPUs. Long story short, this is because of the NUMA architecture of the underlying host.

      If the number of cores per virtual socket on a vNUMA-enabled virtual machine is set to any value other than the default of 1, and that value doesn’t align with the underlying physical host topology, performance might be slightly reduced. Therefore if a virtual machine is to be configured with a non-default number of cores per virtual socket, for best performance that number should be an integer multiple or integer divisor of the physical NUMA node size.

      For more information check the Performance Best Pratices for vSphere 5 and look for NUMA (p22) and vNUMA (p44). http://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.5.pdf

      The second cosideration is licensing. Some operating systems or applications are hard-limited to run on a fixed number of CPUs. For example, Windows Server 2003 Standard Edition is limited to run on up to 4 CPUs. If you install this operating system on an 8-socket physical box, it runs on only 4 of the CPUs. The operating system takes advantage of multi-core CPUs so if your CPUs are dual core, Windows Server 2003 Standard Edition runs on up to 8 cores, and if you have quad-core CPUs, it runs on up to 16 cores, and so on.

      Virtual CPUs (vCPU) in VMware virtual machines appear to the operating system as single core CPUs. So, just like in the example above, if you create a virtual machine with 8 vCPUs (which you can do with vSphere) the operating system sees 8 single core CPUs. If the operating system is Windows 2003 Standard Edition (limited to 4 CPUs) it only runs on 4 vCPUs.

      Note: Remember that 1 vCPU maps onto a physical core not a physical CPU, so the virtual machine is actually getting to run on 4 cores.

      As the licensing is almost never an issue within VDI environments, the decision will primarily be based on performance. But with the number of cores and the huge amount of memory used in modern server hardware, I suspect you will never cross these NUMA borders when deploying VDI desktops.