Installing a VNC server on VDS and tuning recommendations
This guide focuses on virtual servers (VDS / VPS) accessed via VNC over the Internet. This sets the main priorities - economical use of server resources and work on an insufficiently fast channel. As the base system on which the installation is performed, the minimal installation of Ubuntu 9.10 is used. With minor modifications, this guide applies to other Linux distributions and Unix family operating systems, as well as to configure VNC on ordinary dedicated servers and on servers on the local network.
* Methods of organizing the operation of VNC servers
** Built-in VNC server in hardware emulators (Xen / HVM, VMWare, Qemu)
** VNC server attached to a working X server (GNOME vino)
** VNC server with built-in X server
*** VNC server, manually launched
*** VNC server, launched in daemon mode
*** VNC server, launched via inetd
* VNC server selection
* Server
tuning ** Desktop tuning
** VNC server options
The main ways to organize remote work with a graphical desktop on virtual servers:
1. Built-in VNC server in hardware emulators (Xen / HVM, VMWare, Qemu)
2. VNC server attached to a working X server (GNOME vino)
3. VNC -server with integrated X-server
3.1 VNC-server, manually launched
3.2 VNC-server, launched in daemon mode
3.3 VNC-server, launched via inetd
Let's consider these methods and evaluate their advantages and disadvantages.
Many virtualization platforms that support hardware emulation (VMWare, Qemu, Xen in HVM mode) provide the virtual machine with virtual devices - a graphics adapter, keyboard, mouse - simulating the operation of real-life devices. The operating system in the virtual machine treats them like ordinary hardware, without distinguishing the difference. The program that controls the operation of the virtual machine can associate these emulated devices with the built-in VNC server, redirecting information to the virtual adapter of the virtual machine to the VNC client, and transferring information about keystrokes received from the VNC- to the virtual machine’s keyboard customer. For the operating system and programs running in the virtual machine, the existence of a VNC server and a VNC client is invisible,
1. VNC client connected to the VNC server of the Xen virtual machine in HVM mode, when FreeBSD is loaded.
In Xen, enabling a VNC server for a virtual machine is done by specifying the vnc type in the vfb configuration parameter . Additional options in this parameter: vnclisten - indicates the IP address on which the VNC server accepts connections; vncpasswd is the password that the VNC client must provide.
For example, adding the line to the configuration file of the virtual machine:
means the inclusion of a VNC server, which accepts connections at all available IP addresses and requires authorization with the qwerty password.
The main and comprehensive advantage of using the VNC server of the virtualization platform: simplicity - just enable VNC server support in the virtual machine settings.
The main disadvantages: a very large consumption of resources on the site of equipment emulation and a limited number of virtualization platforms that support this feature.
For some virtualization platforms, there is also a less resource-intensive option, in which, instead of emulating a real graphic device, a simplified abstraction, a framebuffer, is transmitted to the virtual machine. Xen supports the framebuffer as a virtual machine graphics adapter; there are screen drivers for the framebuffer for XFree86 and X.org X-servers. When using the framebuffer, the processor and RAM costs for emulating the real hardware are eliminated, but all other shortcomings remain.
The option is best suited for remote access to the desktop of a regular computer (work, home). Access to the desktop via VNC in GNOME is included simply - just enable the Allow other users to view you desktop , Allow other users to control you desktop options in the system menu in the System / Preferences / Remote Desktop section . When they are turned on, the VNC server (vino) included in GNOME is launched, tied to the X server display and completely duplicates the information displayed on the screen for the VNC client.
But on a virtual server, things get more complicated. First, you will need to somehow start the X server, for example, on an emulated virtual machine graphics adapter, and only after that it will be possible to allow VNC access to the display of this X server in the manner described above. Compared to a VNC server on a hardware emulator, there’s only one thing: lower emulation costs. But the remaining disadvantages remain and a new one appears - a more time-consuming setup. All together makes this option the worst candidate for a virtual server.
There are a number of programs - VNC-servers, which independently act as an X-server for applications. Unlike the standard X-server that works with real devices (graphics adapter, keyboard, mouse) or their emulation in virtual machines, the X-server integrated into the VNC server does not need this functional part - instead of hardware, interaction is carried out only with VNC- by customer. The X server built into the VNC server does not require either complex configuration or computing resources to work with the equipment, therefore this option is best suited for virtual servers.
In Ubuntu 9.10, the vnc-server virtual package offers two alternatives as a VNC server: vnc4server (RealVNC) and tightvncserver(TightVNC). There is no significant difference between them, there are only small nuances in their use, which will be described later. Now let's look at vnc4server.
Minimum OS installations for VDS, as a rule, do not include graphical environments, so you will also need to install GNOME. To install the RealVNC server and GNOME, just install two packages:
The default settings allow you to use the VNC server without additional configuration immediately after installation. We start from the command line the VNC server that creates the X server on the zero display (and accepts VNC connections on port 5900):
and on the created zero display, start GNOME:
At the first start, vncserver will ask you to set a password that will need to be entered in the VNC client when connected. To change the password of the VNC server, use the vncpasswd command .
But each time, accessing the server via SSH and starting the VNC server manually is not a suitable option for everyday work. It is preferable to configure the automatic start of the VNC server.
In order not to start the VNC server manually after each reboot, it can be added to the starting procedure. If you wish, you can build a complete set of scripts for upstart, but in practice it’s enough to add a line to /etc/rc.local :
where you need to specify the username of the user for whom the desktop is started as $ USER. If necessary, you can simultaneously run multiple VNC servers for one or different users on different displays.
When the VNC client is disconnected, the desktop session and running programs do not end, but continue to work in the same way as when the VNC client is connected. When reconnecting the VNC client to this display, the user will end up in the same desktop session as if there was no disconnection. Several VNC clients can connect to the same VNC server (X-display), while they will work with the same desktop.
It is possible to start a VNC server only on demand - when connecting a VNC client. To do this, the 5900 VNC server port is handed over to the inetd daemon for servicing. As long as there is no VNC client connected, no VNC server will be started. When a request is made on the connection from the client side, inetd starts the VNC server and connects the client to it. The VNC server creates a display and starts a working session. After disconnecting the client, the VNC server closes the session and terminates all programs working with the display.
If several clients are connected to the same port, a separate VNC server with its own display will be launched for each. Thus, all connected clients will have independent working sessions. This allows using authentication via GDM to easily configure the system for multi-user operation - after the connection, the username and password of the virtual server user are requested, after their correct entry, the working session of this user will be started. 2. User authorization through GDM when connecting to the VNC server. In addition to the already installed RealVNC and GNOME server, we will need to install gdm and xinetd.
First, you need to configure the GDM display manager: allow accepting user authentication requests via XDMCP and disable the start of the X server from gdm. We edit the configuration file /etc/gdm/gdm.conf in accordance with the patch: or save the patch to the file /tmp/gdm.conf.patch and use it with the command: In order for xinetd to start the VNC server, create a configuration file for it / etc / xinetd.d / xvnc with the following contents: Xvnc startup arguments must contain -inetd , letting the VNC server know that it is launched through the inetd daemon, and -query 127.0.0.1
, which means that when the VNC server starts, it will need to authenticate the user through the local display manager (GDM). The -once option tells you that after disconnecting the client, the X server must also be disabled. -SecurityTypes none disables native authorization of the VNC server, as users authenticate through gdm.
We restart xinetd and gdm with the commands: We launch the VNC client and connect to our server. We enter the username and password of the system user, and we get the standard desktop: 3. Ubuntu 9.10, the GNOME desktop.
The main advantage of the c inetd method is the lack of resource consumption for the operation of the X server and desktop programs without VNC clients. An additional plus is full-fledged multi-user work: everyone connects to a standard VNC port, the number of users is unlimited.
In Ubuntu 9.10, the standard distribution has two VNC servers: vnc4server (RealVNC) and tightvncserver (TightVNC).
There are problems with some clients with RealVNC as a server. For example, a number of versions of TightVNC and UltraVNC clients cannot use compression algorithms with this server, which slows down the Internet. The TightVNC server has no such problems with clients. In addition, unlike RealVNC, the TightVNC server supports the Tight encoding algorithm, which allows you to compress data using JPEG - when displaying photos and other complex images, this significantly reduces the amount of data transferred. Otherwise, there are no noticeable differences between the servers.
In the description of installing a VNC server with inetd, all the settings were provided for the RealVNC server. When used as a TightVNC server, small changes to the settings will be required.
The TightVNC server does not require the -SecurityTypes none and -extension XFIXES arguments , so the line of arguments in the /etc/xinetd.d/xvnc configuration file for xinetd should look like this:
You also need to disable keyboard remapping in GNOME, otherwise keystrokes will be transmitted incorrectly . To do this, set the environment variable XKL_XMODMAP_DISABLE. The easiest way to do this is by creating the /etc/X11/Xsession.d/10tightvncserver file with the contents:
The file will be automatically executed when the GNOME session starts.
Desktop settings can have a significant impact on network speed. The task of reducing the amount of transmitted data is reduced to two subtasks: minimizing changes on the screen and using well-compressible images.
The main part of the information the user works with is text: windows with text, menus, forms, etc. The included font smoothing increases 1.5-3 times the amount of data transmitted when displaying text, since the grayscale areas at the borders of characters carry additional poorly compressible information.
You can turn off anti-aliasing in the GNOME font settings window, but this disabling will not work in all programs - for example, Firefox will still smooth fonts. Therefore, it is better to make settings in the system configuration file /etc/fonts/fonts.conf (anti-aliasing of all fonts smaller than 14 pixels is disabled): Volume of transmitted data and display speed on the channel 1 Mbps drop-down menu (color depth: 16 bits, encoding: Tight):
The desktop background can greatly slow down if it contains a photograph or drawing. Any minimization of a window or menu entails a redraw of the portion of the background that was blocked by it. And, the more complex the image, the more data will be transmitted. To minimize background bandwidth costs, it is recommended to use a single-color background, white is best.
The design of interface elements can also affect the amount of data transferred. To minimize traffic, you should choose a theme with flat colors, without gradients. However, many topics that use vertical gradients are compressed quite well and can be used without significant loss in speed.
Reducing the size of fonts for system menus and text fields entails a reduction in the geometric size of text areas, and consequently, a decrease in the amount of transmitted data.
The VNC server has many options, but we are interested in the following three: geometry - screen size, depth - color depth, deferupdate - delay transfer of changes.
Screen size in pixels. Format: -geometry WIDTH x HEIGHT . For example, -geometry 800x600 is 800 pixels wide and 600 pixels high. The larger the screen size, there is a larger amount of data that needs to be transferred - but there is no direct relationship between them. When changing the information on the display, the client is not transferred the entire image of the display, but only the area with the changed information - an open window, an open menu item or a printed character. Therefore, there is no significant gain when using 800x600 instead of 1024x768.
Color depth in bits. Format: -depth NUMBER_BIT , NUMBER_BIT - 8, 15, 16 or 32. The greater the color depth, the better the halftones and shades are shown, but the greater the amount of information required to be transmitted. Reducing the color depth reduces the amount of data, and, accordingly, the speed increases. For working over the Internet, a 16-bit color depth is quite suitable. When using a slow channel (<256 Kbps), it is recommended to use an 8-bit color depth.
The amount of transmitted data and the display speed on the channel 1 Mbps drop-down menu for different color depths (encoding: Tight):
VNC clients can force the use of a reduced color depth of 8 bits (256 colors), while ignoring the color depth specified on the server.
The delay in the transfer of changes on the display, in milliseconds. Format: -deferupdate NUMBER_MILLISECONDS , by default - 40. Allows you to combine in a single update a large number of small screen changes made in the time interval specified in the option. When merging several changes that occurred on the same screen area, the total amount of data transferred decreases. Increasing this parameter impairs interactivity - the visual response to an action is shown on the VNC client only after the deferupdate expires . Given the delays in transmitting data over the network, the total reaction delays can reduce the convenience of work.
Most operations on virtual servers are rendered fast enough, and deferupdatenegative effects can be reduced to 10 ms. On networks with high bandwidth, you can turn off the delay completely by specifying -deferupdate 0 .
Using a VNC server launched through inetd, along with the recommendations made for tuning, allows you to work with the desktop via the Internet, even on entry-level virtual servers. In total, tuning allows you to achieve a reduction in delays of 2-5 times, compared with standard settings. Starting the VNC server on demand allows you to free up RAM for other tasks.
For example, the Ubuntu 9.10 VNC preset assembled using this schemeIt provides acceptable desktop work on VDS with 128 Mb RAM / 320 MHz CPU via 1 Mbps ADSL channel. If you increase the connection speed to 5-10 Mbit / s and the power of the virtual server to 512 Mb RAM / 960 MHz CPU, the work in terms of comfort is closer to working with a local computer. The response time for most interface operations is in the range 0.05-0.2 seconds.
RAM consumption on Ubuntu 9.10 with a VNC server launched via inetd:
Other articles in this series:
VNC - remote access to a computer over a network. Introduction to VNC.
Connect to a remote computer via VNC. Work with the VNC client.
* Methods of organizing the operation of VNC servers
** Built-in VNC server in hardware emulators (Xen / HVM, VMWare, Qemu)
** VNC server attached to a working X server (GNOME vino)
** VNC server with built-in X server
*** VNC server, manually launched
*** VNC server, launched in daemon mode
*** VNC server, launched via inetd
* VNC server selection
* Server
tuning ** Desktop tuning
** VNC server options
Ways of organizing the work of VNC servers
The main ways to organize remote work with a graphical desktop on virtual servers:
1. Built-in VNC server in hardware emulators (Xen / HVM, VMWare, Qemu)
2. VNC server attached to a working X server (GNOME vino)
3. VNC -server with integrated X-server
3.1 VNC-server, manually launched
3.2 VNC-server, launched in daemon mode
3.3 VNC-server, launched via inetd
Let's consider these methods and evaluate their advantages and disadvantages.
1. Built-in VNC server in hardware emulators (Xen / HVM, VMWare, Qemu)
Many virtualization platforms that support hardware emulation (VMWare, Qemu, Xen in HVM mode) provide the virtual machine with virtual devices - a graphics adapter, keyboard, mouse - simulating the operation of real-life devices. The operating system in the virtual machine treats them like ordinary hardware, without distinguishing the difference. The program that controls the operation of the virtual machine can associate these emulated devices with the built-in VNC server, redirecting information to the virtual adapter of the virtual machine to the VNC client, and transferring information about keystrokes received from the VNC- to the virtual machine’s keyboard customer. For the operating system and programs running in the virtual machine, the existence of a VNC server and a VNC client is invisible,
1. VNC client connected to the VNC server of the Xen virtual machine in HVM mode, when FreeBSD is loaded.
In Xen, enabling a VNC server for a virtual machine is done by specifying the vnc type in the vfb configuration parameter . Additional options in this parameter: vnclisten - indicates the IP address on which the VNC server accepts connections; vncpasswd is the password that the VNC client must provide.
For example, adding the line to the configuration file of the virtual machine:
vfb = [ 'type=vnc,vnclisten=0.0.0.0,vncpasswd=qwerty' ]means the inclusion of a VNC server, which accepts connections at all available IP addresses and requires authorization with the qwerty password.
The main and comprehensive advantage of using the VNC server of the virtualization platform: simplicity - just enable VNC server support in the virtual machine settings.
The main disadvantages: a very large consumption of resources on the site of equipment emulation and a limited number of virtualization platforms that support this feature.
| pros | Minuses |
|---|---|
|
|
For some virtualization platforms, there is also a less resource-intensive option, in which, instead of emulating a real graphic device, a simplified abstraction, a framebuffer, is transmitted to the virtual machine. Xen supports the framebuffer as a virtual machine graphics adapter; there are screen drivers for the framebuffer for XFree86 and X.org X-servers. When using the framebuffer, the processor and RAM costs for emulating the real hardware are eliminated, but all other shortcomings remain.
2. VNC server attached to a working X server (GNOME vino)
The option is best suited for remote access to the desktop of a regular computer (work, home). Access to the desktop via VNC in GNOME is included simply - just enable the Allow other users to view you desktop , Allow other users to control you desktop options in the system menu in the System / Preferences / Remote Desktop section . When they are turned on, the VNC server (vino) included in GNOME is launched, tied to the X server display and completely duplicates the information displayed on the screen for the VNC client.
But on a virtual server, things get more complicated. First, you will need to somehow start the X server, for example, on an emulated virtual machine graphics adapter, and only after that it will be possible to allow VNC access to the display of this X server in the manner described above. Compared to a VNC server on a hardware emulator, there’s only one thing: lower emulation costs. But the remaining disadvantages remain and a new one appears - a more time-consuming setup. All together makes this option the worst candidate for a virtual server.
| pros | Minuses |
|---|---|
|
|
3. VNC server with integrated X server
There are a number of programs - VNC-servers, which independently act as an X-server for applications. Unlike the standard X-server that works with real devices (graphics adapter, keyboard, mouse) or their emulation in virtual machines, the X-server integrated into the VNC server does not need this functional part - instead of hardware, interaction is carried out only with VNC- by customer. The X server built into the VNC server does not require either complex configuration or computing resources to work with the equipment, therefore this option is best suited for virtual servers.
In Ubuntu 9.10, the vnc-server virtual package offers two alternatives as a VNC server: vnc4server (RealVNC) and tightvncserver(TightVNC). There is no significant difference between them, there are only small nuances in their use, which will be described later. Now let's look at vnc4server.
Minimum OS installations for VDS, as a rule, do not include graphical environments, so you will also need to install GNOME. To install the RealVNC server and GNOME, just install two packages:
apt-get install vnc4server gnome-core3.1 Manual VNC Server
The default settings allow you to use the VNC server without additional configuration immediately after installation. We start from the command line the VNC server that creates the X server on the zero display (and accepts VNC connections on port 5900):
vncserver :0and on the created zero display, start GNOME:
DISPLAY=:0 gnome-sessionAt the first start, vncserver will ask you to set a password that will need to be entered in the VNC client when connected. To change the password of the VNC server, use the vncpasswd command .
But each time, accessing the server via SSH and starting the VNC server manually is not a suitable option for everyday work. It is preferable to configure the automatic start of the VNC server.
3.2 VNC server running in daemon mode
In order not to start the VNC server manually after each reboot, it can be added to the starting procedure. If you wish, you can build a complete set of scripts for upstart, but in practice it’s enough to add a line to /etc/rc.local :
su -l $USER -c "vncserver :0"where you need to specify the username of the user for whom the desktop is started as $ USER. If necessary, you can simultaneously run multiple VNC servers for one or different users on different displays.
When the VNC client is disconnected, the desktop session and running programs do not end, but continue to work in the same way as when the VNC client is connected. When reconnecting the VNC client to this display, the user will end up in the same desktop session as if there was no disconnection. Several VNC clients can connect to the same VNC server (X-display), while they will work with the same desktop.
| pros | Minuses |
|---|---|
|
|
3.3 VNC server launched via inetd
It is possible to start a VNC server only on demand - when connecting a VNC client. To do this, the 5900 VNC server port is handed over to the inetd daemon for servicing. As long as there is no VNC client connected, no VNC server will be started. When a request is made on the connection from the client side, inetd starts the VNC server and connects the client to it. The VNC server creates a display and starts a working session. After disconnecting the client, the VNC server closes the session and terminates all programs working with the display.
If several clients are connected to the same port, a separate VNC server with its own display will be launched for each. Thus, all connected clients will have independent working sessions. This allows using authentication via GDM to easily configure the system for multi-user operation - after the connection, the username and password of the virtual server user are requested, after their correct entry, the working session of this user will be started. 2. User authorization through GDM when connecting to the VNC server. In addition to the already installed RealVNC and GNOME server, we will need to install gdm and xinetd.
apt-get install xinetd gdm-2.20First, you need to configure the GDM display manager: allow accepting user authentication requests via XDMCP and disable the start of the X server from gdm. We edit the configuration file /etc/gdm/gdm.conf in accordance with the patch: or save the patch to the file /tmp/gdm.conf.patch and use it with the command: In order for xinetd to start the VNC server, create a configuration file for it / etc / xinetd.d / xvnc with the following contents: Xvnc startup arguments must contain -inetd , letting the VNC server know that it is launched through the inetd daemon, and -query 127.0.0.1
--- /etc/gdm/gdm.conf.orig 2009-09-11 23:46:30.000000000 +0400
+++ /etc/gdm/gdm.conf 2009-11-30 02:36:06.000000000 +0300
@@ -311,3 +311,3 @@
# the security of XDMCP.
-Enable=false
+Enable=true
# Honor indirect queries, we run a chooser for these, and then redirect the
@@ -604,3 +604,3 @@
#
-0=Standard device=/dev/console
+#0=Standard device=/dev/consolepatch /etc/gdm/gdm.conf /tmp/gdm.conf.patchservice xvnc
{
type = UNLISTED
disable = no
socket_type = stream
protocol = tcp
wait = no
user = gdm
server = /usr/bin/Xvnc
server_args = -inetd -query 127.0.0.1 -once -SecurityTypes none -extension XFIXES
port = 5900
}, which means that when the VNC server starts, it will need to authenticate the user through the local display manager (GDM). The -once option tells you that after disconnecting the client, the X server must also be disabled. -SecurityTypes none disables native authorization of the VNC server, as users authenticate through gdm.
We restart xinetd and gdm with the commands: We launch the VNC client and connect to our server. We enter the username and password of the system user, and we get the standard desktop: 3. Ubuntu 9.10, the GNOME desktop.
service gdm restart
service xinetd restart
The main advantage of the c inetd method is the lack of resource consumption for the operation of the X server and desktop programs without VNC clients. An additional plus is full-fledged multi-user work: everyone connects to a standard VNC port, the number of users is unlimited.
| pros | Minuses |
|---|---|
|
|
Choosing a VNC Server
In Ubuntu 9.10, the standard distribution has two VNC servers: vnc4server (RealVNC) and tightvncserver (TightVNC).
There are problems with some clients with RealVNC as a server. For example, a number of versions of TightVNC and UltraVNC clients cannot use compression algorithms with this server, which slows down the Internet. The TightVNC server has no such problems with clients. In addition, unlike RealVNC, the TightVNC server supports the Tight encoding algorithm, which allows you to compress data using JPEG - when displaying photos and other complex images, this significantly reduces the amount of data transferred. Otherwise, there are no noticeable differences between the servers.
Differences in setting up the TightVNC server
In the description of installing a VNC server with inetd, all the settings were provided for the RealVNC server. When used as a TightVNC server, small changes to the settings will be required.
The TightVNC server does not require the -SecurityTypes none and -extension XFIXES arguments , so the line of arguments in the /etc/xinetd.d/xvnc configuration file for xinetd should look like this:
server_args = -inetd -query 127.0.0.1 -onceYou also need to disable keyboard remapping in GNOME, otherwise keystrokes will be transmitted incorrectly . To do this, set the environment variable XKL_XMODMAP_DISABLE. The easiest way to do this is by creating the /etc/X11/Xsession.d/10tightvncserver file with the contents:
export XKL_XMODMAP_DISABLE=1The file will be automatically executed when the GNOME session starts.
Server tuning
Desktop tuning
Desktop settings can have a significant impact on network speed. The task of reducing the amount of transmitted data is reduced to two subtasks: minimizing changes on the screen and using well-compressible images.
Font smoothing
The main part of the information the user works with is text: windows with text, menus, forms, etc. The included font smoothing increases 1.5-3 times the amount of data transmitted when displaying text, since the grayscale areas at the borders of characters carry additional poorly compressible information.
You can turn off anti-aliasing in the GNOME font settings window, but this disabling will not work in all programs - for example, Firefox will still smooth fonts. Therefore, it is better to make settings in the system configuration file /etc/fonts/fonts.conf (anti-aliasing of all fonts smaller than 14 pixels is disabled): Volume of transmitted data and display speed on the channel 1 Mbps drop-down menu (color depth: 16 bits, encoding: Tight):
14 false 14 false
| Subpixel Smoothing Enabled | No smoothing | |
 |  | |
| Volume | 30 Kb | 13.8 Kb |
| Speed | 0.24 sec | 0.11 sec |
Desktop background
The desktop background can greatly slow down if it contains a photograph or drawing. Any minimization of a window or menu entails a redraw of the portion of the background that was blocked by it. And, the more complex the image, the more data will be transmitted. To minimize background bandwidth costs, it is recommended to use a single-color background, white is best.
Desktop theme
The design of interface elements can also affect the amount of data transferred. To minimize traffic, you should choose a theme with flat colors, without gradients. However, many topics that use vertical gradients are compressed quite well and can be used without significant loss in speed.
Font size
Reducing the size of fonts for system menus and text fields entails a reduction in the geometric size of text areas, and consequently, a decrease in the amount of transmitted data.
VNC Server Options
The VNC server has many options, but we are interested in the following three: geometry - screen size, depth - color depth, deferupdate - delay transfer of changes.
geometry
Screen size in pixels. Format: -geometry WIDTH x HEIGHT . For example, -geometry 800x600 is 800 pixels wide and 600 pixels high. The larger the screen size, there is a larger amount of data that needs to be transferred - but there is no direct relationship between them. When changing the information on the display, the client is not transferred the entire image of the display, but only the area with the changed information - an open window, an open menu item or a printed character. Therefore, there is no significant gain when using 800x600 instead of 1024x768.
depth
Color depth in bits. Format: -depth NUMBER_BIT , NUMBER_BIT - 8, 15, 16 or 32. The greater the color depth, the better the halftones and shades are shown, but the greater the amount of information required to be transmitted. Reducing the color depth reduces the amount of data, and, accordingly, the speed increases. For working over the Internet, a 16-bit color depth is quite suitable. When using a slow channel (<256 Kbps), it is recommended to use an 8-bit color depth.
The amount of transmitted data and the display speed on the channel 1 Mbps drop-down menu for different color depths (encoding: Tight):
 | |  | |
| Color depth | 24 bits | 16 bit | 8 bit |
| Volume | 15.2 Kb | 13.8 Kb | 9 kb |
| Speed | 0.12 sec | 0.11 sec | 0.07 sec |
VNC clients can force the use of a reduced color depth of 8 bits (256 colors), while ignoring the color depth specified on the server.
deferupdate
The delay in the transfer of changes on the display, in milliseconds. Format: -deferupdate NUMBER_MILLISECONDS , by default - 40. Allows you to combine in a single update a large number of small screen changes made in the time interval specified in the option. When merging several changes that occurred on the same screen area, the total amount of data transferred decreases. Increasing this parameter impairs interactivity - the visual response to an action is shown on the VNC client only after the deferupdate expires . Given the delays in transmitting data over the network, the total reaction delays can reduce the convenience of work.
Most operations on virtual servers are rendered fast enough, and deferupdatenegative effects can be reduced to 10 ms. On networks with high bandwidth, you can turn off the delay completely by specifying -deferupdate 0 .
Conclusion
Using a VNC server launched through inetd, along with the recommendations made for tuning, allows you to work with the desktop via the Internet, even on entry-level virtual servers. In total, tuning allows you to achieve a reduction in delays of 2-5 times, compared with standard settings. Starting the VNC server on demand allows you to free up RAM for other tasks.
For example, the Ubuntu 9.10 VNC preset assembled using this schemeIt provides acceptable desktop work on VDS with 128 Mb RAM / 320 MHz CPU via 1 Mbps ADSL channel. If you increase the connection speed to 5-10 Mbit / s and the power of the virtual server to 512 Mb RAM / 960 MHz CPU, the work in terms of comfort is closer to working with a local computer. The response time for most interface operations is in the range 0.05-0.2 seconds.
RAM consumption on Ubuntu 9.10 with a VNC server launched via inetd:
| Running programs | RAM used |
|---|---|
| server without connected VNC clients | 41 Mb |
| one VNC client, GNOME desktop | 80 Mb |
| two VNC clients, two GNOME desktop sessions | 127 Mb |
| one VNC client, GNOME desktop, running Firefox, the site www.ubuntu.com is open | 121 Mb |
| one VNC client, GNOME desktop, OpenOffice.org text editor launched | 112 Mb |
Other articles in this series:
VNC - remote access to a computer over a network. Introduction to VNC.
Connect to a remote computer via VNC. Work with the VNC client.