Home

I’ve got some performance numbers. My test environment: Win'2003 showing some dynamic coub video, raspberry model B/512M running a bit overclocked (core @800Mhz with scaling governor set to 'performance'). DFreerdp built with Release config (LFDY config didn’t used it in this testing since it gives near to unmeasurable difference) according to instructions found here: http://blog.pi3g.com/2013/07/high-performance-rdp-on-the-raspberry-pi/. I found that performance very depends on selected encryption/compression settings. Compression can be enabled/disabled by -z option for dfreerdp while encryption can be disabled by setting to 'Low' RDP encryption policy on server side (Execute on server gpedit.msc, then go to Computer confuguration → Administrative Templates → Windows Components → Terminal Services or Remote Desktop Services and there enable policy named 'client connection encryption level' and set its value to 'Low'). Note that reducing encryption level increases security risks, so do that only if you will use RDP in trusted infrastructure. I measured performance with following modes: compression and RDP encryption enabled, compression enabled + encryption disabled, compression disabled + encryption disabled. The last one however is fastest visually. But as performance metric I used raw averaged traffic rate from server to client and compared results taken from different builds (with and without my changes) but with same settings, using fullscreen mode (-f option). So:

• No compression, no encryption: 2.37 times faster.

• Compressed, no encryption: 2.04 times faster.

• Compressed, encrypted (client compatible lvl): 1.87 times faster.

However memory usage also noticeable lowered due to eliminated some redundancy of bitmap data. Also when VT with running in full-screen mode (-f option) is deactivated - then it tells server to suppress all paints until activated back. That saves CPU and network bandwidth when keeping more that single fullscreen session connected while switching between them. Also I implemented so-called '--direct-surface' option. Using it even more reduces memory usage and amount of memory copying-s needed for update image. But there is also drawback: mouse cursor flickers during pending screen updates.