by Andre Leibovici

VDI Display Protocol Calculator v1.1 w/ New Features

I am making available an updated release of my online Display Protocol Calculator. This new release implements a number of features to better size protocol bandwidth utilization, VMware View 4.6 with PCoIP Gateway support, and also an experimental (!) feature to calculate the bandwidth offset when multiple simultaneous sessions.

In my original post VDI Display Protocol Calculator v1.0 I explained how display protocols are often over-provisioned during the design phase. With exception to very specific use cases where there is multicast involved it’s not common to see workloads where all users simultaneously fully utilize the network bandwidth allocated to their User Profile. The non-utilized bandwidth accumulates and the higher the number of users is; additional free bandwidth should be available. I call it Bandwidth Offset.

This release of the calculator offers the ability to specify what offset (%) that should be applied to the bandwidth consumption. Because the offset is only evident when there are multiple simultaneous sessions I have set a hard minimum limit of 30 users before offset can be activated. Additionally, offset is applied starting from at the2nd half of the user spectrum, given that there might be only a minimal offset before that. The total offset bandwidth consumption is displayed along with the Regular Total Bandwidth.

A nice graph will demonstrate the comparison between the total bandwidth consumption and the Regular Total Bandwidth. The offset range allowed is from 10% to 50%, and this percentage is proportionally distributed across the last 5 increments.

The Bandwidth Offset calculation is NOT, in any way, calculated using numbers, formulas or algorithms provided by Teradici or VMware. This feature is offered in experimental mode without any warranties and it is based on my own experience and tests in lab and production environments.

Audio Quality

Audio remoting is also responsible for bandwidth consumption and just like video streaming it should be taken in consideration for sizing purposes. In PCoIP audio is automatically compressed depending on the available network bandwidth. In constrained network environments, the audio compression is increased to reduce the network footprint. When congestion is alleviated, the audio compression is reduced to take advantage of the available network bandwidth.

However, if you design is meant to guarantee high quality audio across a number of users you will need to take that into consideration. Teradici’s guideline for the audio stack is as follows:

For RDP, the audio remoting stack caps the audio signal being transmitted to 22 kilohertz (kHz), resulting in a maximum theoretical bandwidth of 86 KBps /11 kpbs. The RDP stack then compresses the audio signal further by using in-box audio codecs. The choice of the codec is determined by codecs supported by the client and server, as well as the bandwidth available between the client and the server. Consequently, RDP can only utilize Compressed Mono and Mono audio without degradation of the audio quality.

Taking that into consideration I have added the ability to specify how many users will be doing remote audio and what quality is expected. Because most bandwidth sizing guides already include some type of audio redirection the calculator will only consider the difference when Stereo or CD quality (stereo) audio are selected.

Shanmugam

Very insightful analysis. However, there is no cap on audio bitrate as said in the article. RDP 7 and above employ a number of different codecs (ranging from stereo ADPCM to mono GSM codecs) – Choice of codec is based on what the client supports and the available bandwidth.