Решения для управления доменами Windows Active Directory

How to configure the TightVNC remote control tool (screen sharing)?

How can I optimize the use of TightVNC?

I use your tool IDEAL Administration and TightVNC for taking control remotely of machines located on my local network or on a remote site and I find the response times quite sluggish.

The purpose of this page is to show you ways in which you can improve your installation, explaining the various parameters you can tweak if you want to reduce response time when taking control remotely.

When refreshing the screen, fluidity and speed are affected by a whole range of parameters: the remote station's processor, the network throughput between the two points, the performance of your local graphics card, the data encoding and type of compression used, etc.

You're therefore going to have to find the best compromise between processor usage, compression time, and transfer time!

I. Hardware acceleration

One trick you can try, if for example the remote station is a server, is to completely deactivate hardware graphics acceleration.

To do so, click on the Windows desktop with the right mouse button and select Properties. A "Display Properties" control panel appears. Click on the Settings tab, the Advanced button, then the Troubleshoot tab. Slide the pointer completely to the left ("None"). Confirm the setting by clicking OK both times.

Try taking control remotely again. You should see a noticeable improvement in performance.

Remarks:

1. This option is not necessarily available on every workstation or on every operating system. You need to check out its presence in each case.
   
   
2. Never try doing this if the workstation has an ATI graphics card: some of these cards are known to provoke a BSOD (Windows crash) when this feature is deactivated.

II. Display properties in TightVNC

This is the most effective means for optimizing remote processor resource usage.

In the TightVNC configuration panel, click on the "Connection" tab and go to the "Update handling" section. Now uncheck "Poll full screen" and make sure only the following boxes are checked: "Poll Foreground Window", "Poll Console Windows Only", and "Poll on event received only".

These parameters give a fully acceptable result for Windows graphic type applications.

For DOS applications, it's a little less sure.

Our own tests show that TightVNC's use of processor resources seldom exceeds 30% when the parameters are set as above. Using the default configuration, i.e., with full-screen refreshing, processor resource usage can easily top 70% or even 80%.

III. Encoding of screen images

It's a case of playing with the various algorithms that can be used for encoding screen data during transfer. There's clearly no one solution that covers every need. If there was, we would have implemented it!

What we suggest is that you consult the test results page on the official TightVNC site at

https://www.tightvnc.com/

This will help you get a better understanding and appreciation of what goes on (in terms of data volumes and compression times) when you chose one algorithm over another. (English only)

If you want to optimize your connection, therefore, you're going to have to try out all the different parameters and find out which combination is the best for your particular needs. The result will then need to be translated into command line arguments for the "VNCViewer Command Line" section of the "General" tab in the TightVNC configuration tool.

The main arguments to look at are:

"-encoding tight": This is the default value and the argument that gives the lowest transferred data volume. It's what you need if you are taking control remotely via a modem or ISDN line.
It will however cause a fair amount of latency due to the compression and expansion stages.

"-encoding hextile": This gives the least compression time. It is no doubt your best bet for a local area network, whatever its configuration.

"-encoding raw": No compression takes place: processor usage is therefore kept to a minimum at both ends, but there will be a huge volume of data shipped from the remote station to yours.

There's another switch you can use in conjunction with these arguments: /8bit. This limits the color depth to 8 bits, i.e. 256 colors. You'll lose out a little on quality, but you will win in terms of required bandwidth, hence speed.

One last solution, when running TightVNC with the "tight" algorithm, is to play with the JPEG encoding and compression ratio settings.

JPEG quality can be set to between 0 and 9, with 0 being "worst" and 9 being "best".

The compression ratio can be set to between 1 and 9, with 1 being "mildest compression" and 9 being "strongest compression". The default settings are compresslevel = 6 and quality = 6.

Here are some examples:

"-compresslevel 9 -quality 0" will give full-strength data compression with a more or less lousy image, but the volumes transferred will be quite trivial. Keep this one for low throughput connections (modem, ISDN, WAN).

"-compresslevel 1 -quality 6" will give a near perfect quality image, and its minimal compression makes for near negligible processor usage.  

Example of some command line combinations:

"-encoding tight -compresslevel 6 -quality 6": The default setting!
"-encoding tight -compresslevel 9 -quality 0": Maximum compression, minimum volume.

"-encoding hextile": The fastest option for use with a LAN
"-encoding hextile -compresslevel 1 -quality 5 /8bit": Worth trying!

IV. Using in conjunction with Zebedee

As is the case with all tunneling software, packets are compressed before sending them through tunnels. To perform this compression, processor resources are of course required.

Moreover, TightVNC itself uses all sorts of compression algorithms to reduce the size of the images going through the "pipe" to the controlling machine. This tool requires processor resources.

But here's the rub: compressing data that's already compressed often leads to an increase in size, so you lose out twice!

Consequently, if you use TightVNC in conjunction with Zebedee inside your local network, we advise you to modify the contents of the following file:

* Program FilesPointdevIDEAL AdministrationZebedeeVNCViewer.zbd

Add the following line (or modify it if it's already there):

compression 0

From now on, every time you take control remotely from this administration machine, the data will no longer be compressed in the Zebedee tunnel.

V. Using "DFMirage" mirror video driver

The mirror video driver DFMirage is a TightVNC add-on which improves graphics rendering. In particular, it includes management of transparency effects (OS Vista and higher, Office 2007 menu button...) and it is also supposed to improve connection speed.

To copy the driver installation file on the remote host, please verify in the TightVNC remote control configuration (General tab), that the box "Copy video driver (DemoForge Mirage) when installing the service) is checked.

Then, after having launched the TightVNC control on the remote host, the driver could be automatically and silently installed, directly from the TightVNC viewer ("Mirror video driver manager" button). Depending on the remote host OS, you will be probably asked to certify the program (via the "publisher verification of the driver software" window). Then please click on "Install this driver software anyway".
Once the installation is completed, you can verify that the driver has been correctly installed by opening the "Device manager" -> "Display adapters" and looking for the "Mirage Driver" entry

It may be necessary to re-launch TightVNC so that the driver is supported after installation. However, be careful because known compatibility problems may arise in some configurations and OS (read more).