How Much Bandwidth Does VNC Require?

jhartnagle asks: "For VNC (Virtual Network Computing) we are trying to determine what the minimal bandwith would be on a network and still have a functional experience for the user (no or very little lag/latency). Information on any type of network connection would be useful, 10/100Mbps, cable/DSL, and modems. What are some of the setup parameters for the machine that would be the VNC server, x number of bits for color for example. Are there any white papers about VNC, bandwidth requirements and usability? Also, is there similar information about telnet? How low of baud rate can you go before it stops being functional? We would be interested in any academic and practical information. Thanks!" So does anyone have any rules of thumb or words of caution in allocating enough bandwidth here? Better yet, are there any good hints in accomplishing VNC over relatively low bandwidth networks?

Comments

parameters to greatly increase performance

[Raleel]

especially over a slow connection...

ssh -C -L localport:vncmachine:remoteport and tunnel it

vncviewer -encodings "hextile"

of course, I have not gotten to try tightvnc.

Over ~600kbps it works fine.

[Doco]

My situation - my home is hanging off an 802.11 network and I get about 600kbps over that (give or take). My work is connected via T1 and we are about 9 hops away. Ping times around 60-100ms.

I used VNC all day yesterday with screen resolutions of 1600x1200 @ 32 bits.
Windoze 98 client, Windoze NT server.

General performance was "ok". Pulling up a new window had a 1 second or so of lag, and once in a while the rxvt or xemacs screen wouldn't update until I clicked or did some typing in the window. I noticed it most if I was watching while I typed. Then it was ok sometimes, and sometimes I ran into more lag and could be 10-20 characters ahead in my typing from what was being displayed.

I have tried using TightVNC which works ok - but I 've also had some stability problems with it. It is supposed to work better for low bandwidth applications, but I haven't been able to do a side-by-side type of comparison.

VNC usage

[OctaneZ]

Note: this is not based on any white papers, but rather years of usage. VNC server from experience is much more adept on UNIX servers than on Windows. Remember if you are running Windows you can always change the polling to change what part of the screen gets updated (use less bandwidth). Another option to reduce bandwidth (this works on all servers/clients) is reduce the color to 8bit. Also the speed of the connection at the server is more important than at the client end. I have used a client on a Dial-up (29.6 kbps) to connect to windows and unix servers on a T1 line. Remember to keep your software up to date, as they make improvements to handling regularly.
-OctaneZ

"I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones."

TightVNC

[const_k]

Well, TightVNC has been mentioned here already but being the TightVNC developer, I'd like to add a number of points.

First, to make things clear, TightVNC is a VNC version which mostly concentrates on low bandwidth usage. It can be more than usable on modem connections (starting from 14.4 kbps) but actual bandwidth requirements strongly depend on screen contents and color depth. If you want best performance over a slow link, first of all remove colorful wallpaper from your desktop (and maybe restrict color depth to 8 bits in VNC viewer).

Next point. Most users know TightVNC for its 1.1 version which may be considered outdated at this moment. TightVNC development has made notable progress since then and bandwidth requirements are decreased a lot. Although new 1.2 release is not ready at this point, but (1) there are preview versions including most 1.2 functionality and (2) I hope it will be released less than in a week counting from now (I only have to do several changes in Win32 version).

To let you know more what TightVNC is, here is a brief list of features for upcoming release, from new version of its homepage:

• Local cursor handling. Cursor movements do not generate screen updates any more, remote cursor movements are processed locally by the viewer, so you do not see remote cursor pointer moving too slow behind the local cursor.
• Efficient compression algorithms. New Tight encoding is optimized for slow and medium-speed connections and thus generates much less traffic as compared to traditional VNC encodings.
• Configurable compression levels. You can choose any appropriate level of compromise between compression ratios and coding speed, depending on the your connection speed and processor power.
• Optional JPEG compression. If you don't care too much about perfect image quality, you can enable JPEG coder which would compress color-rich screen areas much more efficiently (and image quality level is configurable too).
• Operating under Unix and Windows. All new features listed above are available in both Unix and Win32 versions of TightVNC.
• Web browser access. TightVNC includes Java viewer with support for Tight encoding and local cursor feature (viewer applet may be accessed via built-in HTTP server as in the standard VNC).
• Automatic SSH tunneling on Unix. Unix version of TightVNC viewer can tunnel connections via SSH automatically using local SSH or OpenSSH client installation.
• And more. A number of other improvements, performance optimizations and bugfixes, from me and from other people.

As you can see, most major changes introduced in TightVNC are related to efficient bandwidth usage.