Remote Display Analyzer 2.0 released

Hi all,

I want to begin with a big thank you for all the positive feedback about Remote Display Analyzer (RDA) and also a very big thanks to the members in the sponsor program, this really helps to drive RDA forward and to help balance the amount of time spend in this project by giving something back to the family. So thank you very much for becoming a sponsor!

If you are new to Remote Display Analyzer (RDA), this tool will help you understand your remote display configuration and it’s behavior, it will only show you relevant information and help you decide which setting is the best for your specific use case. It’s also very handy for troubleshooting remote display configurations. RDA is just a portable executable without any installation needed, just run it in your remote session and you will get all relevant statistics and settings right away.

There is a lot of new functionality in RDA 2.0, both under the hood as on the outside. I don’t want to make this a long article so I will just give you a short summary of the new features together with some print screens.

What’s new in version 2.0

  • Support for VMware Blast and PCoIP with also the possibility to change settings on the fly (please note that support for Blast and PCoIP is experimental in this release and not yet tested on different OS and VMware View versions)
  • GPU addon for all protocols: This addon will show basic GPU information and when Nvidia is detected RDA will show GPU usage and (v)GPU information
  • Support for the latest Citrix HDX features like H.265, also the RTT counter has been added and RDA will show you the YUV mode for the active video codec
  • RDA is now multi threaded which means that settings and real-time counters are retrieved on different threads making the tool more snappy and more real-time
  • Counter that indicates the run time of RDA with the option to reset the counter and the total statistics collected during  a specific run time. This is handy for analyzing and comparing workloads
  • Print screen option to easily generate a print screen of the RDA window
  • Multiple improvements for RDP & new statistics information
  • Transparent mode, this option makes the RDA window transparent as you can see in the below print screen

Below you will find some print screens of RDA 2.0

RDA running in transparent mode

RDA support for VMware

GPU addon (available for all protocols) and extended support for HDX

Remote Display Analyzer 2.0 is now available for free on the website where you can also find more information about the sponsor program. Existing sponsors should have received an automatic e-mail about this new release. If you didn’t receive the mail please send an e-mail to Thanks again for your support!

Using ThreadLocker to control runaway applications

threadlockerLately I was troubleshooting some performance issues in a XenApp 6.5 environment, the customer was observing 2 issues 1: degraded performance in user sessions and 2: scalability problems.  The root cause of this issues was fairly easy to detect when looking at the performance history of the XenApp servers :  A (cr)application was hitting the CPU constantly which causes CPU spikes and overall performance degradation. The environment wasn’t using any form of CPU management other than the default CPU Dynamic Fair Share Scheduling (DFSS) feature in 2008 R2. While DFSS does a great job in equally distributing CPU resources amongst user sessions, the problem with this application is that it’s running away in every user session resulting in overall performance degradation of other applications and lower scalability of the XenApp farm.

While the software vendor is looking at the issue (I will not call the vendor by name because I don’t want to “name and shame”) a community tool developed by Andrew Morgan named ThreadLocker came to mind. ThreadLocker is a tool that can change the CPU affinity and priority of processes on the fly.

In this blog post I will show you how ThreadLocker is helping to improve the overall performance and scalability by changing the CPU affinity of the process that causes the CPU spikes on the fly. Beneath is a snapshot of the CPU usage before ThreadLocker was running, this spikes are caused by the application running in different user sessions.


The task list reveals the application running away with the CPU resources :


So I installed ThreadLocker and configured the affinity of the process to CPU core 0 and 1, I didn’t changed the priority because this caused the application to hang completely  :


ThreadLocker is very light weight and runs as a background service so it does its job in every user session, nothing to configure at a per user basis. After ThreadLocker is running it changes the affinity of the process to CPU core 0 and 1 at a custom interval  :


After ThreadLocker is active notice CPU core 2 and 3 on the right when the users start using the application :


ThreadLocker will also write its activity in the event logs when the verbose logging option is switched on, in this way you can check how often ThreadLocker switches the affinity.

Conclusion :

In this blog post I showed you a good use case for ThreadLocker, with this tool you can tie processes to certain CPU cores to free others. In this way the run away application cannot consume all CPU resources on the XenApp servers so other applications have always free CPU resources to use. Please note that in this use case it’s not a permanent solution for this issue, by binding the process to less CPU cores the application itself has less resources to consume and will perform slower, but that weight is much lower than the performance and scalability impact in the whole environment. We will use ThreadLocker here till the software vendor has fixed the issue and ThreadLocker will be in my Toolbox when I come around this kind of situation again.

You can download and read more about ThreadLocker here.

Please note that the information in this blog is provided as is without warranty of any kind.