Производительность и загрузка процессора

Every network, every machine, every piece of hardware, every driver, and even every link in-between can vary dramatically in performance. Therefore, within the DameWare Mini Remote Control program we have provided our users with a multitude of settings, and also made the software as flexible as possible, so that tweaking these performance settings within the software can produce acceptable results under any possible scenario.

We also recommend that you don’t focus on any single setting as an answer to your given situation. All factors should be taken into consideration when performing any type of performance tuning. Therefore, we suggest that you take a look at all the information provided below before beginning with your performance tuning.

Performance:

There are many factors that affect the speed of a MRC connection, and many more that are completely outside of our control, such as: CPU, memory, video hardware, video drivers, NIC hardware, NIC drivers, etc…

A very large factor that affects the speed of the MRC connection is the color depth on the remote machine. Therefore, you should try enabling the "Force 4-bit" or "Force 8-bit" options under the Display Options Tab (select your host entry, then click on the Setting button, and then select the Display Options Tab). For Example: a remote machine running 1024 x 768 resolution and 32-bit color depth has to send approximately 4MB of data across the wire to paint the screen on your local machine. Whereas enabling the "Force 8-bit display" for this connection would only require about 780K of data. That’s over a 75% savings in data transferred, just by reducing the color-depth.

Another large factor that affects the speed of the MRC connection is large bitmaps on the remote machine’s desktop. Therefore, you should also try disabling the remote machines Wallpaper, pattern, and font smoothing (select Settings button, then Remote Options Tab). Large bitmaps as well as high color depths on the remote machine will definitely decrease the performance over the connection. Disabling Active Desktop on the remote machine should also help.

Another big factor that affects speed as well as CPU utilization is the remote machine's Video Card & Video Drivers. Unlike NetMeeting and Remote Desktop that are integrated within the Operating System itself, the Mini Remote Control program (and most all Remote Control Programs) simply use standard Microsoft Windows API calls to interact with the Operating System and the Video Card/Video Drivers on the local and remote machines to basically "scrape" the screen. In other words it reads the remote machine's Video Memory. However, there are also many factors that are outside of our control, such as old/outdated/faulty hardware, old/outdated/faulty drivers, and even slow or poorly configured memory that could also affect the performance of the connection.

Version 4.5 and above actually included a significant performance enhancement over older versions of the software, however, not by using the same "older" performance settings that worked in older version of the software. For Example: For machines in my local LAN, I was able to set the compression to 0, set my scan blocks to around 14, and set my Delay between Scan Block Updates between 3 & 5 and achieve much faster performance (near real time) on machines in our Local LAN. For connecting to my home machine over a 128k VPN connection, I personally use Compression=9, Scan Blocks=32, Delay=5-10 and I don't have any issues with performance or CPU% what-so-ever.

Increasing the Scan Blocks will divide the remote monitor’s display into an increased number of "bands" or rows. Initially, the entire screen is send over and displayed on your monitor. After the initial screen is displayed, only the bands that change are sent from the remote machine back to yours, thus reducing the amount of data being sent back and forth.

You can also try tweaking the Compression settings as well. If you have a fast network link, then you can try reducing Compression because it does take time & resources to compress & decompress data sent across the pipe. However, keep in mind that when reducing the Compression that you could potentially be sending a large amount of data over the wire. For Example: A remote machine running 1900 x 1200 resolution at 32-bit color with Compression set to 0 (Zero) would have to send 9MB of data over the wire to paint the entire screen. For slow network links, try increasing Compression to 9. This may take a little more time to compress & uncompress the data, however, this would also reduce the amount of data sent over this slow link, and thus it should help with performance.

CPU:

With most hardware today CPU% really should not be an issue and CPU% over the MRC connection is typically less than 10%. However, even at 80-90% CPU usage, it should not really be an issue because the Mini Remote Control program is designed to yield to other running processes. However, just as stated above, you should also be able to tweak the performance settings within the software to reduce the CPU%.

A big factor which increases CPU% is Encryption. Therefore, turning off all the different encryption options (select Host Entry, click on Settings, click on Encryption Options Tab) should also help with CPU utilization

Another big factor that affect CPU%, as well as speed, is the remote machine's Video Card & Video Drivers. The Mini Remote Control program simply uses standard Microsoft Windows API calls to interact with the Operating System and the Video Card/Video Drivers on the local and remote machines. However, there are also many factors that are outside of our control, such as old/outdated/faulty hardware, old/outdated/faulty drivers, and even slow or poorly configured memory.

Reducing Compression (possibly even to 0 depending on bandwidth availability), & increasing scan blocks and delay between scan blocks should also help with CPU utilization as well. I would also suggest that you try the "Force 4-bit" or "Force 8-bit" options under the Display Options Tab, and even try disabling the remote machines Wallpaper, pattern, and font smoothing, and also disabling Active Desktop. Personally I use: Compression=0, Scan Blocks=14, Delay=3 for machines in my local LAN and it's basically near real time. For connecting to my home machine over a 128k VPN connection, I personally use Compression=9, Scan Blocks=32, Delay=5-10 and I don't have any issues with CPU or performance at all.

Please also note that although these suggestions may reduce the CPU%, they may also decrease feedback/performance during the MRC connection, but you should be able to find a balance between these settings that works for your specific environment.

One last thing to keep in mind is that you should not view the Task Manager/CPU usage over the MRC connection, because the Task Manager's Refresh will actually add CPU%, so it would not be an accurate number. Therefore, you should really view it remotely, for example via the NT Utilities Processes View, to get a more accurate number.

Also, in version 4.8 and above, our developer was also able to make some additional enhancements with regard to performance. If you have modified the default settings, then select your specific Host Entry, then click on the Settings button, then click on the Default button to reset these settings back to the default settings. It is very important to Reset the Settings back to Default; otherwise you will still be running your old settings. The new default settings are Compression=3, ScanBlocks=32, & Delay Between Scan Blocks=12.

In our testing, we were able to reduce the CPU% on one machine from 30+% to around 6% just by using the new default settings.