PCoIP: Unleash the Throughput

PCoIP is a dynamic protocol and contains some very advanced mathematical algorithms to detect the ideal bandwidth, throughput, image quality and codecs to be utilised to stream contents to endpoints. These algorithms utilise arguments such as latency and variance to create what is called ‘rto’ metric. The higher the ‘rto’ the worse is the user experience. When ‘rto’ is close to 100 that’s when the link is in good conditions for a great user experience.

Couple examples of rto captured from log files are:


Before you continue reading this article I recommend you to get familiarised with PCoIP log files, troubleshooting and managing PCoIP display quality. I have previously published the following articles: How to troubleshoot PCoIP performance and Optimising PCoIP Display & Imaging that will provide you with the base knowledge.

In addition the rto metric PCoIP measures the amount of Packet Loss during Receiving and Transmitting period. (T)ransmission is data flow from the virtual desktop to the end point device.


No news here, bust just to recapitulate. PCoIP is a UDP based protocol and maintain packet transmission without having to acknowledge (ACK) the reception of the UDP packet for every datagram received at the endpoint device. However, every couple milliseconds the endpoint device sends acknowledgements and provides statistics back to the PCoIP server (aka virtual desktop). The example below demonstrates the bandwidth being dynamically decreased (throttled) in a single PCoIP session. In this case it was required to decrease the bandwidth several times because of packet loss.


Based on these statistics PCoIP dynamically decide if bandwidth must be throttled; however it will always attempt to increase it again if the conditions allow for, and if needed.

That brings me to the point I would like to raise in this article. When PCoIP classify rto or Packet Loss as high the session is throttled. This happens dynamically because PCoIP is trying to auto preserve the end user experience making sure video and image displays are not affected by link issues.

Because multiple sessions share a same WAN link with regular Packet Loss all sessions may be throttling themselves. In this situation PCoIP will not burst and fully utilise all the link bandwidth available.

PCoIP will start throttling sessions when Packet Loss is as low as 1%. The higher the Loss more bandwidth is throttled. Maybe I am being a little redundant here but I just want to make sure this is understood.

Now, in some situations where Packet Loss is common, such as ADSL links, administrators may prefer to pump as much data as possible and flood the links even when packet loss is high. Even with Packet Loss around 8-10% users that do not require video streaming should not notice the missing pixels because the screen is constantly refreshed. The refresh rate fps can also be configured and I have previously discussed that.

Currently there is not a publically known mechanism to change the algorithm PCoIP uses to calculate the bandwidth; however is it possible to define the minimum bandwidth available to sessions before the algorithm initiate the throttling mechanism.

The key pcoip.device_bandwitdh_floor sets a lower limit to the bandwidth reserved by the PCoIP session.

This parameter sets a lower bound on the expected bandwidth transmit rate for the endpoint. This parameter can be used to effectively reserve bandwidth for an endpoint. This improves the responsiveness because a user does not need to wait for bandwidth to become available and also guarantee that PCoIP will not throttle below this level even if there is Packet Loss or high rto.


Note that it is important to ensure that for a given configuration, the sum of all the floors for all connections does not exceed the network capability (over-subscribing). It is not difficult to flood the entire link if the parameter is not configured properly. Set PCoIP session bandwidth floor in kilobits per second.

The example above sets the parameter to 1000Mbps (Megabit) however you may set it as high as you want. I have customer who decided to use it as high as 10000Mpbs. That is equal to 1250KB/s (kilobytes per second). Here is a nice calculator to help you.

In VMware View 4.5 this parameter is also configurable applying the PCoIP.ADM templates to AD. For the other parameters in the picture above I have discussed them at Optimising PCoIP Display & Imaging.


2 pings

Skip to comment form

  1. Maybe you mean kbps not megabits… 1000Mbps is one gigabit/s !!!

  2. @[email protected]
    Thanks for the note. I’ll fix the typo.

    • TheOX on 02/11/2011 at 12:49 am

    Hi Andre,

    congratulations for your exceptional blog, full of interesting and technically accurate articles.

    Second paragraph, the short form for “acknowledge” should be “ACK” and not “aka”. “aka” is correctly used as “also known as” immediately after. Just a little typo. 😉

  3. @TheOX
    Thanks for congratulations.I also fixed the typo.


    • Derek on 09/09/2011 at 12:04 pm

    I read places where the RTO is supposed to be lower the better and vice versa. I have great experience with RTO of 180, and not so great at 170. Currently I am experiencing very low loss connection but the RTO is 240 so the user experience is sluggish to respond.

    When troubleshooting user experience I have only looked at RTO and Loss (A/I/O) but this one scenario I am currently having with the RTO of 240 and very little loss doesn’t make sense.

    Do you know how RTO really is calculated?

  4. @Derek
    RTO is a complex calculation using all variables. If you want me to analyse your issue, please send me the PCoIP server log file to [email protected]

  1. […] is a great article, PCoIP: Unleash the Throughput at http://myvirtualcloud.net which goes into depth on the […]

Leave a Reply