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

One data point

[Anonymous Coward]

For a while I tried using a VNC server on Windows with an X-based VNC viewer on Linux. This is on a 10Mb/s ethernet network: the server and client were about five hops away.

It was so slow as to be unuseable. Response latencies, repaint times and things not repainting when they should were constant problems. All and all it might be useful to do something quick, in an emergancy, but I never want to be subjected to it again. I'll stick with X thank-you-very-much

Re:One data point

[tzanger]

It was so slow as to be unuseable. Response latencies, repaint times and things not repainting when they should were constant problems. All and all it might be useful to do something quick, in an emergancy, but I never want to be subjected to it again. I'll stick with X thank-you-very-much

Try turning off "Poll entire screen" in the VNC server. I'm using TightVNC (google search it if you want it) over a DSL link to a VMWare session on a Cel450 located on moderately-loaded T1 and it's responsive enough to almost program over. (1024x768x32) -- if I drop to 8 bit colour it seems to get a little laggier but the screen updates are faster (duh).

The trick for me was to make sure that "Poll Full Screen" was DISABLED. VNC is totally unusable over a 100mbps switched network if that option is set. I have all the others set (Poll window under cursor, foreground window, console windows and on event received) -- don't worry about the "only" clauses on some of them, that seems to be incorrect.

vnc over wan

[riffraff]

I connect to our win2k server over an adsl link, which is 128k going out. It is fine. Yes, it is a little slow, but better than having to drive over to the other office just to create a user id, or change permissions on a file. I even do it over an encrypted ssh tunnel.

vnc security

[complex]

it may be a bit off-topic, but it's worth mentioning, esp. since the poster included cable modems/dsl in his question.

please please please use the AuthHosts setting if you have VNC installed on a publically accessible ip. it limits access by ip, ranges and wildcards are acceptable.

considering the relatively weak default password sceme in vnc (including no delay in missed password attempts and no default attempt logging), it's a good first step in securing access.

complex

Re:For all these people

[Finni]

Well, they can't use TS if they are sitting at anything but another Windows box. (OR maybe a Macintosh, if Mac IE supports ActiveX.) In fact, I haven't been able to install the TSAC (Terminal Services Advanced Client) on a Win98 box. It says I have the wrong version of Windows. I had to load the NT TS 4.0 client, which I haven't been able to find on MS' site. The advantage to VNC is the multiplatform capability. The client can be a PalmPilot, a HP, a Mac. Also, not every application runs well under TS. If someone wanted to check the status of a legacy application, that application might not handle a non-console session well. I know that the Norton AV client gets confused by remote sessions, so there may be other apps that have similar difficulties.

Server speed?

[GregWebb]

OK, can't find information elsewhere and this is _nearly_ on-topic :-)

I've just been presented with an ancient computer, which I'm thinking of extremely gentle uses for. At the moment it'll probably get used to take printer load off a desktop or two, which it should manage well enough.

Anyway. Looking at where it's going to be dumped, I'll be happier if it doesn't have to have a monitor, keyboard or anything like that. So, if VNC will run it's rather useful.

We're currently looking at a P120 running Windows 95 (original) with 16MB and 600MBish free drive space. Oi, no laughing! Yes, it might be getting more RAM and a bigger HDD if we can come up with a strong enough motivation and find some SIMMs... I don't mind turning it down to 640*480 @ 16 colours, I don't care if it'll be slow because I'll hardly ever use it. It would be running over 100Mb ethernet so bandwidth isn't a problem.

But would it work at all? Honestly, I can't find this sort of information at the moment!

Thanks,

Have a look over here

[Aphexian]

I was surprised no one had mentioned TightVNC, yet.

It is supposed to be anywhere between 5 and 75% thinner than even plain zlib compression on a VNC stream.

The original goal appears (to me) to be usability over a dial-up. There are unix as well as win32 variants.

Hope that helps, good luck!

Check out www.rdesktop.org

[Raleel]

The rdesktop project implements RDP 4 (aka terminal services) on most unix platforms. I've been using it for the better part of a year as my only windows desktop. It rocks.

I might also add that I have had no problem whatsoever with norton on terminal services.

And as for a win98 client, you can make one off your win2k server. Look under your control panel.

Re:Check out www.rdesktop.org

[Bazzargh]

Very nice. Notice though that Tim Edmonds has been
posting that he's working on bringing together
the rdp code with the vnc code to allow you to
get round the slowness of vnc on windows servers -
simply take advantage of the rdp server.

Why? Well, why would you want an rdp client when
you can manage all of your boxen (not just windows
or X) - from all of your boxen, with vnc?

-Baz

Re:Check out www.rdesktop.org

[Bazzargh]

whoops I should have followed all the threads. The rdp2vnc work is now available, having been completed by James Weatherall:
http://www.uk.research.att.com/~jnw/downloadable s/

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.

Re:Telnet does require a fast network (what!?)

[dublin]

PPP is notoriously heavy - that's why many of us (when we were unfortunate enough to have to dial into the net) refused to use PPP, but insisted on ISPs that supported CSLIP instead. It's a little less common, but CSLIP (also known as SLIP with Van Jacobsen (VJ) header compression) is quite a bit more efficient than PPP - do the math for yourself to see the reduced overhead...

FWIW, I love VNC and use it nearly every day, but if you're trying to remotely control a Windows machine and it's running W2K server or better, I'd stick with the Terminal Services stuff, which is quite a bit faster than any VNC. Also, the VNC clients for some platforms (CE is one notable example) are terrible, while there are pretty good TS clients available (surprise, surprise...)

FWIW, VNC is very good software, even if it's not the fastest thing out there. I used to work for Tivoli, which sells a really expensive remote control product as part of its management solution. When I showed VNC to the RC team (this was 2-3 years ago), they were amazed, impressed, and recoiled in horror once they realized that there was a completely free solution that worked better than the one we charged megabucks for. (But then that sort of thing was, sadly, true of most all of Tivoli's software...)

I prefer the Tridia VNC to other VNC "distros", but YMMV, especially if you want Constantin's latest Tight encodings, on which Tridia seems to lag a bit.

VNC speed

[AtariDatacenter]

I can't give you a direct answer, and a lot of it depends on the application you are doing and how its drawing algorithm compares to X. It also depends on what settings you have on your VNC. (And I am assuming we're talking a VNC client on Windows and a VNC server on UNIX.)

I can say that Netscape on X-Windows over a VPN was DOG SLOW to the point of being near unusuable (Netscape mail, specifically). Switching to VNC over my VPN made things dramatically faster.

Of course, VNC doesn't quite act the same as a perfect X interface.

Comparison paper at USENIX

[Bazzargh]

There was a paper with benchmark comparisons of Citrix (ICA), WTS (RDP), VNC, and SunRay thin clients at usenix.

http://www.cs.columbia.edu/~nieh/publications/us en ix2001_slowmotion.pdf

Summary:
'Overall, VNC and Sun Ray were faster at higher
network bandwidths while Citrix and RDP performed
better at lower network bandwidths.' (this on a web browsing test)
They also did a streaming video test which basically seemed to show everything except SunRay got processor bound at high bandwidths and that 'visually,
only Sun Ray achieved good performance even at 100
Mbps.'

From your point of view another interesting observation was that VNC sends less data than the others at low bandwidths. ie, the other protocols were still trying to to real time updates, VNC just began to appear sluggish as it waits for client responses. However in the words of the report 'none of the platforms
provide good response time at 128 Kbps'

-Baz

Re:If you're using Unix server with windows client

[1010011010]

X-Win32? Blah. The Unix version of the VNC server (it's actually just an X server) works great. X provides a lot more information to VNC than windows, and in an event-driven manner, so that VNC can do minimal updates with good results. The Windows GUI essentially has to be polled, which is why you'll often see WinVNC eating 80-100% CPU on windows while doing even simple things, while on unix it barely makes a dent.

- - - - -

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.

Re:If you're using Unix server with windows client

[ikekrull]

I would recommend XFree86 4.x for Windows, it has been available for some time now, compiled with Cygwin/Mingw32.

Works great, and costs nothing, unlike X-Win32, which works great, but costs a lot.

Re:VNC usage

[OctaneZ]

>>Also the speed of the connection at the server is more important than at the client end.
>What on earth does that mean?
What I meant by this was that the amount of available bandwidth, be it dialup, 1.5mbps, 10mbps, etc. seems to have a greater improvement on the connection, when the increase is at the server side.
eg (just an example): The conection seems to be much better when you connect from a Dialup Client to a T1 server; than from a client on a T1 line to a server on a dialup line.
-OctaneZ

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

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."

Re:VNC usage

[raju1kabir]

What I meant by this was that the amount of available bandwidth, be it dialup, 1.5mbps, 10mbps, etc. seems to have a greater improvement on the connection, when the increase is at the server side.

That's what I thought you meant. It doesn't make any sense.

The observable characteristics of an end-to-end link are latency, bandwidth, and (if not handled by protocol) data loss.

It is not possible to determine, in band (i.e., leaving aside out-of-band tricks like traceroute and pathchar), at which end these characteristics are being affected.

So what you say is pretty close to impossible.

Perhaps what you're observing is the 33Kb ceiling on upstream traffic with 56Kb modems on analog POTS lines.

Re:VNC usage

[raju1kabir]

Also the speed of the connection at the server is more important than at the client end.

What on earth does that mean?

Re:VNC usage

[GreyPoopon]

That's what I thought you meant. It doesn't make any sense.

Well, yeah, it does -- maybe. If you take the server being on a dial-up connection and the client being on a T-1 as the example, and the server is doing something over that connection besides just sending VNC images, then that little tiny dialup pipe will have much more impact on the server than if the situation were reversed. Usually, a client will be doing nothing over the connection except VNC, while the server may be doing many other things (including file sharing, web server, etc).

Perhaps what you're observing is the 33Kb ceiling on upstream traffic with 56Kb modems on analog POTS lines.

Absolutely, this would have an observable effect. Most connections on a 56K modem are around 46K (downstream, of course). The difference between 46K downstream and 33K upstream (13K) can be pretty significant.

GreyPoopon
--

For all these people

[SuiteSisterMary]

For everybody saying that they use VNC to admin Win2k, I ask WHY? Almost everything you need to do you can do through computer management; if you actually need a remote desktop, use Terminal Services (In Server, Adv Server and Datacenter Server) in Remote Control mode; it's much much faster than VNC will ever be. There's even TSAC which runs in a web page (activeX, admittedly).

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.

Re:Telnet does require a fast network (what!?)

[raju1kabir]

No offense, but how old are you? Did you never use telnet (or telnet-like BBS systems) before the web? 9600 is plenty fast for a telnet connection.

What he's saying, and he's quite correct, is that telnet isn't always terribly responsive.

A direct-dialed 2400bps connection to a BBS is certainly more responsive than telnet over a 56K PPP link. That's simple math (protocol overhead), not to mention the empirical observation of anyone who's tried both.

Re:Telnet does require a fast network (what!?)

[raju1kabir]

Protocol overhead? BS. It's the routing overhead that gets you. Your 2400 was a direct connection.

Every character your type in a telnet session gets packaged up in a TCP packet inside an IP packet inside a PPP packet, ballooning it to a dozen or more bytes.

Every character you type when modemmed directly to a BBS gets sent as exactly one byte (okay, yeah, except for escape sequences).

LBX (Low-Bandwidth X)

[slashdot_commentator]

Food for thought:

Latest version of X incorporated a low bandwidth protocol. You run a binary on the remote end called lbxproxy, direct your DISPLAY to it, and then communicate through the lbxproxy. Haven't tinkered with it much, so I can't give much comparison to VNC. (I would imagine Tight VNC would perform better than either LBX or standard VNC. Also not sure if there is a version of Solaris that supports it.)

If you're using Unix server with windows clients

[Genoaschild]

I would recommend X-Win32. It's a little expensive, over $100 a pop, but works really well over 10 mb/s network. If you're doing it the opposite way around, VNC is probably you're best option. Just keep the servers local and use a network with as much bandwidth as possible.
----

Eh?

[houTTni]

I'm not sure what is going on with these other guys. I am running a Win2k Server box at home (no flames please) on cable modem (normally 40 up and 300 down) at 800x600 and 32bit and from my work (90mb fiber ring connected to our 10/100 switch) I get great speeds over VNC. I do use the 8bit pixel restrictions to speed it up even more.

Over the local 10/100 at home there is no lag at all.


"Press any key to begin."