Remote Support
Remote Access
Remote Work
Remote Monitoring and Management
Remote Presentation
Standard
Business
EnterpriseSpeed in Remote Desktop Applications
The speed and responsiveness of a remote access session is often the factor that determines whether potential customers choose to purchase SimpleHelp or not. Yet optimising SimpleHelp purely for speed has a detrimental effect on other aspects of the software, including bandwidth usage and security. For instance, avoiding data compression results in a more responsive session on high bandwidth connections, but a poor experience on low bandwidth, or high latency ones.
SimpleHelp strongly encrypts and compresses all data transferred, yet is still able to capture, process and transmit millions of pixels per second. On my test machine, which has over two millions pixels, SimpleHelp is able to capture and process the entire screen in 20 milliseconds, supporting up to 50 frames per second! How can it then be that we recently received the following comment from a long-time customer:
SimpleHelp strongly encrypts and compresses all data transferred, yet is still able to capture, process and transmit millions of pixels per second. On my test machine, which has over two millions pixels, SimpleHelp is able to capture and process the entire screen in 20 milliseconds, supporting up to 50 frames per second! How can it then be that we recently received the following comment from a long-time customer:
For some reason, when I connect to a Win2003 Server machine on my LAN it takes two seconds to receive each screen update. All of my other machines are very responsive. What can I do to improve performance?
Further investigation showed an interesting diagnostic: CPU usage during the faulty session never reached 20%, indicating that for 800ms of each second the CPU was idle. What they could be causing such long capture times?
The answer lay in the server’s video hardware. The operating system was composing the visible screen contents by amalgamating them together, on the card itself, issuing updates to the card and having the card render the contents to the monitor. The traditional data path, from CPU to video card, was highly optimised by the card’s device drivers, but the reverse from card to CPU was not. The result was incredibly slow back transfer of screen data, and subsequently a lag-filled session.
“What can I do to improve performance?” In this case, disabling hardware acceleration reduced capture times from seconds to 30 milliseconds, increasing the frame rate from 1/2 per second, to 15 frames per second.
The answer lay in the server’s video hardware. The operating system was composing the visible screen contents by amalgamating them together, on the card itself, issuing updates to the card and having the card render the contents to the monitor. The traditional data path, from CPU to video card, was highly optimised by the card’s device drivers, but the reverse from card to CPU was not. The result was incredibly slow back transfer of screen data, and subsequently a lag-filled session.
“What can I do to improve performance?” In this case, disabling hardware acceleration reduced capture times from seconds to 30 milliseconds, increasing the frame rate from 1/2 per second, to 15 frames per second.
