For desktop VMs using VMXnet3 NICs, you can significantly improve the peak video playback performance of your View desktop by simply setting the following registry setting to the value recommended by Microsoft:

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

[As discussed in a Microsoft KB article here]

[N.B. A reboot of the desktop VM is required after changing this registry setting]

When running full-screen videos at 1080p resolution on a 2vCPU desktop, we see this deliver frame-rate improvements of up to 1.4X.

So, what does this do and why does it deliver these benefits?

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 ParametersFastSendDatagramThreshold to the Microsoft recommended value of 1500 bytes you instruct Windows not to wait for the completion interrupt even when sending larger packets. Accordingly, you are allowing View and PCoIP (as well as other applications that send larger packets) to benefit from interrupt coalescing – reducing CPU load and improving network throughput for PCoIP  — which translates into significantly improved video playback performance.

In addition to the numerous enhancements detailed here, View 5.1 debuts a number of significant enhancements and optimizations to the PCoIP protocol. In this blog, we detail some of the most beneficial: 

PCoIP efficiency

Continuing refinements to compression protocols and general performance optimization deliver further improvements in PCoIP efficiency and corresponding reductions in CPU consumption. While already performing better than the VDI competition (as illustrated here and here), these enhancements deliver up to an additional 1.3X reduction in PCoIP overheads.

Client optimizations

For this release, there has been significant optimization of the VMware View clients, making their protocol handling significantly more streamlined. This is especially apparent on thin-clients, where video playback performance is improved by as much as 3X over previous versions, as illustrated in the figure below. Indeed, even relatively low-performance processors can deliver excellent 720p video playback performance. These improvements are available for both x86 and ARM clients.

Network improvements

PCoIP handling of adverse network conditions has been significantly improved. This is especially beneficial for users connecting wirelessly from tablets or laptops over congested and lossy WiFi networks. These enhancements are most apparent during video playback and ensure fluid high-frame video playback — the improvement can be as high as 8X.

Interactivity improvements

Significant improvements have also been made to interactivity, making interaction with the remote desktop significantly more fluid, and continuing to further improve the experience associated with using a remote desktop. As a simple visual test of this improvement, the picture below show a user rapidly drawing a spiral in mspaint, when connecting to their remote desktop using both RDP7 and View 5.1. With RDP7, the resulting spiral is obviously formed from rough polygons, whereas, with View 5.1, the spiral is significantly smoother (while this test may seem an overly simple example, it is heavily influenced by the speed and frequency at which the client communicates with the remote desktop and clearly conveys the likely differences in scrolling and dragging performance – in a later blog we will deep-dive on interactive performance, using the user experience techniques we discuss here).

We have talked in previous posts about the ability in View 5 to disable build to lossless (BTL). When BTL is disabled, PCoIP rapidly builds the client image to a high quality, but lossy image — by default, if the image remains constant, PCoIP would continue to refine the image in the background until it reaches a fully lossless state. Stopping the build process when the image reaches the "perceptually lossless" stage can deliver significant bandwidth savings — for typical office workflows, we are seeing around a 30% bandwidth reduction.

Furthermore, in many situations, the difference between fully lossless and perceptually lossless images can be virtually impossible to discern. During our VMworld presentation, we used the following image to emphasize the quality of perceptually lossless:

In this qualitative comparison, we present a zoom-in of two small images. For both images, View fully lossless and View perceptually lossless (no BTL) images are shown side-by-side for comparison — hopefully conveying how difficult it is, even when zoomed, to find differences.

To further emphasize the perceptually lossless quality, it’s also interesting to examine quantitative data — for example, PSNR (peak signal to noise ratio) and RMS (root-mean-square) error data. For a fairly complex image — a fall-colors landscape with significant fine detail in the background tree colors — comparing the perceptually lossless build to a fully lossless build (RGB space), yields a PSNR value of 45.8dB, and RMS error value of 1.3! This clearly illustrates how little loss in quality is associated with perceptually lossless images. For instance, consider the RMS error of 1.3: for 32-bit colors, each rgba component has 8-bits of precision, with values ranging from 0 to 255. For this image, perceptually lossless is introducing an average error of +/-1.3 to these values — fairly negligible for most use cases!!

[While PSNR ratio obviously varies from image to image, I'm seeing ~45dB much of the time]