EUC Tip 88: Adjusting PCoIP offload At Low Bandwidth?

When the network bandwidth for a session goes below 5 Mbps by default, display offloading is cancelled. Once the network bandwidth is above the 6 Mbps by default. The display(s) are eligible for offloading again based on the VM priority and Hardware Accelerator resource availability.

You can adjust the bandwidth for enabling and disabling the card but at lower bandwidth rates features in PCoIP software, such as client image caching will most likely provide more value.

Lots of WAN users? Probably not much need for the card. What about GPU’s in the mix? Check out


EUC Tip 85: GPU Pairing with View 5.2

Just like pairing a fine cheese with the perfect side to please the senses and your appetite, you must do the same for your new GPU with View 5.2.

For your GPU users you want to match the MaxAppFrameRate with the PCoIP frame rate. If your GPU is rendering a workload higher than the PCoIP Max you’re wasting resources for no real gain.

HKLM\SOFTWARE\VMware, Inc.\VMware SVGA DevTap\MaxAppFrameRate


For more performance information read this whitepaper from VMware,



Horizon View: PCoIP Transport Header

There isn’t a good way to sex up this title! New Horizon View 5.2 documenation finally calls out a GPO setting that was there since 5.1, Configure the PCoIP transport header. It will be intresting to see what vendors will come out with features to take advantage of the this new header. My money is on Riverbed and F5, I guess we wait and see.
[Read more…]


#EUC Tip 82: Be the Hunter – PCoIP

Tip 3 from BriForum slide deck was all about making sure your giving PCoIP some your priority on the network. If you don’t set QofS for PCoIP all your traffic gets set to scavenger class since the traffic is UDP based. PCoIP is a real time protocol just like voice and video, small hiccups can negatively affect user experience. Large amounts of bandwidth doesn’t mean you’ll have good a experience.
[Read more…]


#EUC Tip 81: Pedal to the Metal

When the network turns its back on you, you turn your back on the network! Ok, this attitude won’t get you very far but this next tip can help you out when working with packet pushers.

The bandwidth floor variable is a PCoIP session variable to control how much traffic to send to the client without checking to see if any traffic is getting dropped. The virtual desktop will keep sending PCoIP packets as minimum and will not try to throttle you down past this point.

There is a great article, PCoIP: Unleash the Throughput at which goes into depth on the subject

If you are having bad performance with PCoIP, turn this value up. If the issue gets better the buffers on your switch are probably discarding packets or at the very least you need to vist the Network Checklist and get sorted with your networking team. Caution: This setting can end up flooding your network, use it carefully.

variable: pcoip.device_bandwitdh_floor


#VDI Tip 78: Watch Out for USB Drivers

PCoIP errors

URBOIP :process_urb_sync_reset_pipe: Filtering pipe reset for device 0x2a01, pipe 0x813a1300 (ISO)

If you see the line above in your zero client logs you could have a USB driver issue. Windows does a great job for the most part at getting the drivers right but this can crop up time to time. If you can tie it back to the last device that user plugged into their zero client, you can install the driver into the base image.

PCoIP has a token system for USB(URBOIP). When a reset happens on the USB, a token is taken away, no more tokens no more USB. These resets can affect the audio/video for your zero clients so if you’re experiencing bad performance you can start to look here.


#VDI Tip 68: Use Overridable Administrator Defaults for PCoIP Session Variables

Why is there two different settings for PCoIP Session Variables and which should I use?

Overridable Administrator Defaults contains settings that specify PCoIP session variable default values, which can be overridden by an administrator. These settings write registry key values to HKLM\Software\Policies\Teradici\PCoIP\pcoip_admin_defaults.

Not Overridable Administrator Settings contains the same settings as the Overridable Administrator Defaults folder, but these settings cannot be overridden by an administrator. These settings write registry key values to HKLM\Software\Policies\Teradici\PCoIP\pcoip_admin.

Local machine settings are held in the registry keys in HKLM\Software\Teradici. If the same registry key is present under both HKLM\Software\Teradici and HKLM\Software\Policies\Teradici, the group policy setting in HKLM\Software\Policies\Teradici overrides the local machine value.

I prefer setting the PCoIP Session variables as “Overridable”. You are using these settings per pool basis via GPO to give the best overall experience for your users. This will allow you to cater to most of your users but allow for some flexibility for the odd use case that tend to crop up. If you start implementing a hundred and one PCoIP GPO’s you will have more to maintain during upgrades and more to troubleshoot.
The flexibility comes in the form of using different settings on your zero client and soft clients. Zero clients are easy to make different settings but the software client can be changed with a text file. VMware KB -> has the full steps to create the text file. The below steps are from the KB article.

1. Create a file called pcoip_client_settings.txt using a text editor such as notepad.exe.
Settings in this file only take effect on the client.
2. Save the file to C:\Documents and Settings\\Local Settings\Application Data\Teradici
where is the login user ID.
3. Enter they key/value pair for the session variable that you want to override.
Enter one key/value pair per line, seperating the key, ‘=’ character, and value with spaces.
For example: pcoip.device_bandwidth_floor = 1000


#VDI Tip 64: Follow the Network Checklist

Funny thing about Virtual Desktop Infrastructure, it usually relies heavily on the network. Most of my last two days has been spent troubling shooting dropped PCoIP packets, so I feel it’s timely to make sure you have your basis covered.

So here is the big tip of the day, Read and follow this check list – PCoIP Virtual Desktop Network Design Checklist

Networking isn’t my strongest skill but luckily I work with some really smart people. I think the biggest take away from the checklist is WRED.(Weighted Random Early Detection). It provides preferential traffic handling for packets with higher priority. It can selectively discard lower priority traffic when the interface begins to get congested. Try to get your PCoIP traffic prioritized just under VoIP traffic. The above document notes ” Do not configure WRED on the physical interface as it will override all other QoS policies”. Most traffic monitoring tools are not granularity enough to catch the spikes in traffic. In the land PCoIP, 1 minute intervals does not pass the test.

If you have access to your Cisco Router, you can check for drop packets by using the CEF (Cisco Express Forwarding) commands.
show cef drop
show ip cef switching statistics

You can also check for high CPU utilization. Sometimes high CPU utilization will cause buffering. Buffering = BAD

Run something different than Cisco? Please comment and leave commands for other vendors.


Xangati has Huge Announcement at Tech Field Day: User Based Performance Profiling

I told people tonight that I wasn’t going to write a blog post till later but I clearly can’t sleep so here it goes.

The Xangati Presentation was spot on today at Tech Field Day. Right from the start to the end of their presentation they come to play with appropriate content and information that was timely for the Virtualization and End User Computing(EUC) industry. I will get right into the meat of the their content. They did some great marketing but you’re here at this blog because you want to better your VDI environment. Before getting started I also feel it’s necessary to make it known that I am a current Xangati customer.

So the biggest news of the day that was announced via Xangati, User Based Performance Profiling. The current best practice is to implement a VDI environment is use a non-persistent desktop architecture. The basis of the non-persistent desktops is to split the user persona and applications from the desktop. Non-persistent desktops allow Disaster Recovery (DR) and availability by not having to worry about OS problems. If there is an issue, just grab a different desktop. Who cares about the desktop? Next time you log in with a non-persistent desktop you get a clean image, no matter what the heck you did before in your session.

Doesn’t that sound great? If you are able to pull a non-persistent desktop architecture off, there hasn’t been a proper way to monitor and trend what the user is doing after the fact. Monday you are on VDI and your desktop is “desktop-23”. You log off and next Tuesday morning you grab “desktop-06”. Same thing goes on and on and on. There hasn’t been a way to tie the users activities to performance until recently. While the User Based Performance Profiling is still a future, it’s close. The code is done and it’s being ran in beta.

Current things I love about the product:

    The ability to monitor PCoIP\HDX metrics from the Client to the VM
    Monitors Ready Time, Storage Latency, IO rates, Network Latency, Memory spikes, CPU, spikes
    Insight into the applications being ran on the desktop via WMI
    All metrics are trended and you get alerts based on difference varying form “normal” activity”
    Able to create views or groups of applications that you want to specifically track
    vDS integrated via Net Flow. No need for agent VM’s on your hosts(vSphere 5 only) Video
    Drill down features to get to the root problem

Things that could be better:

    Active Directory integration for user accounts is lacking
    Adding new desktops to monitor is a manual process to get added to the dashboards

Luckily the two things that could be better are things were Xanagti has been listening to their customers. Both pieces should be covered in the next release.

The product has a great framework in place for also monitoring Unified Communications along with VDI. I can see Xangati being bought soon by one of the big vendors. Agent-less monitoring that is vendor diagnostic, Powerful.

Great Overview of the Xangati presentation: Musings of Rodos

Thoughts from the Wahl Network: A Combination Of Bacon, Star Wars, and Performance Monitoring

More Information about Xangati can be found here.


#VDI Tip 61: Be Careful when using Client-side Caching with Thin Clients

Client-side caching provides huge bandwidth savings with VMware View 5. Client-side caching can save 30-40 percent of the overall bandwidth. The default size is set to 250 MB and can go up to 300 MB. With older thin clients that have less the 1 GB of RAM you may run into issues. If the client-side cache is set too high, you may start experiencing dropped sessions.

Thanks to Chuck Hirstius, the Master of PCoIP at VMware for making me aware of this issue. Give him a follow at @rexremus