Slashdot Mirror
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?
Most of this stuff is mentioned in the getting started section at the VNC page.
If you're going to be doing this over a WAN, use SSH to tunnel. Again the VNC page has some good directions on how to do this. The benifits to using VNC through SSH are three fold. First you know that eveything is reasonably secure, and another benifit, is that with SSH you can use data comprestion. As far as I know you can't do this with standard VNC. I use the highest level of compresion I can before my connection starts to get wacky. Also another big beifit is, when the 1337 kiddies try to do a port scan on your server, VNC won't show up as an listing port. The VNC page also has a list of some good windows SSH clients and servers. Also keep your resolution low ie, 800X600, and 8bit depth. This should save on some more bandwith. Another thing I have noticed (on my LAN), the cpu on the server machine makes a ton of diffence. On my switched lan at home, I have a p200MHZ box running a Redhat 7.0, and when I VNC into it from 1 hop, the session totaly lags... Now if I'm at work on our butt slow lan, and I VNC into another RH 7.0 box about 7 hops away, I get a really decent session. The work server had a pIII 850 in it. These are just a few things to consider. Also, if your trying to do this on win2K, or NT, I would go with PC anywhere, or the termial service in NT Server, and Win2k Server. They both IMHO run a little better than VNC on that platform.
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
I use VNC to do remote administration of Windows 2000 servers (don't ask, I prefer using SSH with our *BSD and Debian boxes) over a 14.4K connection on a Kyocera Smartphone (Palm based cell phone) and I find it very usable for starting and stopping services, dealing with Active Directory and our backup tape libarary software. On a full screen redraw I might have to wait a few seconds, but it's rather usable. Oh yeah, our servers sit on a 1.5 Mbps link to the Internet.
Would I use it for word-processing over that 14.4K link? No way. But then I don't need to do that.
Please tell us a little more about what programs you are planning to run via VNC and I'm sure someone else here has already tried and will relay their experience.
Host vnc1
HostName machine.com
Compression yes
CompressionLevel 9
LocalFoward 5900 vncmachine 5900
This way I have machine.com accessable to the internet (through a firewall) for ssh, and have it forward the vnc ports to the nt machine (not accessable from the internet).
All I did for the nt machine was install winvnc, set up the password.
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.
Netscape was unusable with lbxproxy the last time I tried (client: RH6.1, server: solaris 2.5.1), which was about a year ago. For me, VNC has been much faster, although it is still not enough for me. I need to look into this Tight VNC thingie, as any thing that makes work-from-home easier is a good thing.
"in a hurry to get second post and forgot the not" Forgot what not? Are you ___ making sense today? (Oops, I forgot the not)
Don't forget to take a look at TridiaVNC. They seem to update the code more often.
---
Sig Return: 204 No Content
MOST COOL! Why hasn't this been modded up to a 4 or 5!?
I just downloaded and compiled it...works VERY well and is VERY fast...nice.
Thanks for letting us know!!!!
---
Sig Return: 204 No Content
It depends on many different parameters.
It might matter what sort of server you're running.
It probably depends on what size of screen you're sending.
It definitely depends on what applications you're running.
It definitely depends on how much you're willing to tollerate lag.
Anyway, my experience has been with using a Linux client and a Windows NT server with a fairly small screen and a fairly calm application. (By "calm," I mean it's not changing things on the screen a lot.) I found that over ISDN, it was just too slow to be worth bothering with. Over a cable modem, it is perfectly usable. Hence, 128Kbps is not enough, but for my use, 1Mbps is adequate, though I still notice lags.
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
While I agree that 9600 baud is fine for a connection to a bbs or for telnet. The protocol that telnet uses relies heavily on round trip time rather than the speed of the line for it's speed. Telnet is also IP based and has a much lower network utilization than many other applications. At time telnet can feel pretty tight at 56k because of these conditions. It's still a good protocol though. The real question being how well connected the host is by hops rather than how well by bandwidth, but bandwidth can exacerbate the problem. Telnet IS much more comfy on cable. Bare in mind that I recently moved from my 28.8 connection from an appartment at school, to a different state, and a cable connection... and telnet is much happier of here than it was there. Of course, the servers also have much lower load now than they did then, so it's really a circular argument. The point of the argument really was that telnet is a different beast from a BBS on a local dialup.
TightVNC code has been folding into TridiaVNC.
== I am not Me.
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.
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,
Greg
(Inside a nuclear plant)
Aaaarrrggh! Run! The canary has mutated!
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!
Maybe I'm talking out the wrong end of my anatomy here, but if there is any buffering, there should be a number of race conditions going on. I would guess that the system is better behaved if the bottleneck is closer to the client than the server. If the bottleneck is closer to the server, it is likely to be committed to keep plugging away at something that is already destined for the bit bucket. Offhand, I'd say the phenomenon could be rather startling, something like the initial discovery of thrashing.
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.
-- Who is the bigger fool? The fool or the fool who follows him? --
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.
-- Who is the bigger fool? The fool or the fool who follows him? --
With a Windows VNC client, and a Windows VNC Server at 1152 x 864 @ 32 bits (client forcing 8 bit), I can use VNC for everyday tasks. There is a noticable lag on screen updates, but nothing that can't be lived with.
Under the same setup, with a Linux VNC server at 1200 x 900 @ 16 bits (not forcing to 8 bits), I get better speeds.
...try TightVNC. It's a new compression technology added to VNC. It's availble from tightvnc.com. I have found that it is more than usable over a 56k connection even if you are using the java applet in Netscape. The patches are GPLed, just like VNC so there are no unneeded restrictions on using it. Setting your bitrate is a different issue. If you are going to have people accessing via the Java applet, use a 8bit depth. Java can only handle 8bit, and dithering takes forever. If you are going to use the standalone clients (available for all major OSes), then use a depth of 16bit or 24bit. The dithering in the standalong clients is much faster than it is in Java.
If you need it, I also have a patch for VNC that only allows one session and then kills the server. It will even run a script on exit if desired. Drop me an email if you would like a copy. I would link to a page for it, but I heven't tested it in a high-load production setting yet.
-Carl "No, we already thought of that one. 'Why?' '42' - It doesn't fit." -Hitchhiker'
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.
"The future's good and the present is nothing to sneeze at." - Roblimo's last
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.
There was a paper with benchmark comparisons of Citrix (ICA), WTS (RDP), VNC, and SunRay thin clients at usenix.
s en ix2001_slowmotion.pdf
http://www.cs.columbia.edu/~nieh/publications/u
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
I would strongly recommend against anything using anything less than ISDN (128kbps) on the client side; I tried running a VNC client over a 28.8kbps modem connection to a server at by school (which I think had 6 T1 lines at the time) and I nearly went insane because of the high latency.
"It take 9 months to bear a child, no matter how many women you assign to the job."
I use VNC over my 192k SDSL line to access my PC at work in order to use Bloated Notes from home (yes, supposedly NOTES would work with WINE, but the VPN software doesn't like that), and to access intranet web pages. It's not the most lively interface, but it's ok for light use. (OTOH, I also typically have two telnet connections going at the same time, and I think there's a bit of a bottleneck in the VPN access that reduces the effective bandwidth even more.)
I use the -bgr233 option to set 8-bit color, it helps a lot though it uglifies things a bit.
Tom Swiss | the infamous tms | http://www.infamous.net/
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
Yes, I have version 5.0 and its shareware. It runs for 2 hours before you have to shut it down and start it up again. I actually think of this more as a feature.
It helps me keep track of how long I have been working and gives me an excuse to take a short break every two hours.
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.
- - - - -
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
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.
Are you using the latest version? I'm not getting the bahaviour you discribe.
"And the meaning of words; when they cease to function; when will it start worrying you?"
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.
I gots ta ding a ding dang my dang a long ling long
>>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."
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."
ML View. ;-)
It's a beta, but hey, we're on Slashdot
They claim, that it is MUCH better lbx Stuff from X.
Plz. moderate this up, I think it's a rather useful project, that needs a few good hackers.
Bye egghat.
-- "As a human being I claim the right to be widely inconsistent", John Peel
I actually use a Palm VNC client running over my GSM phone at 9.6.
The purpose of this is, that I Hotsync over a dialup connection to the Office network.
Sometimes the Hotsync manager dies during the sync. Then I can use VNC to start the Hotsync Manager again.
This does require a LOT of patience, but it works (and the nerd in me gets a little kick out of it, each time)!
Spoiled brat ;-).. try telnet over a 300bps acoustic coupler SLIP connection. (no, not CSLIP, SLIP) 10 yrs ago.
But then again, who knows how many /.ers actually remember what KA9Q is and how to use it.
Speed corrupts. Absolutely.
Cheers,
Chris
Poof.
ever hear of ssh
The current Slashdot moderation system is made by gay communists!
We used VNC for several years on our servers, but when the time came to evaluate it for remote desktop control (troubleshoot from home via SSH tunneled VNC), it fell pretty short. We eventually decided to go with Remote Administrator for a couple of reasons: 1. cheap ($700 site license) 2. more efficient than VNC (10-30% utilization on our web servers vs VNC's 30+) 3. easier to setup and configure using the same OpenSSH tunneling setups Radmin has proven to be a very effective "middle-of-the-road" solution between freeware VNC and big-$ remote access solutions.
Show me what you want, and I'll show you how to get along without it...
I have used VNC on a LAN and over the internet (DSL <-> Frac. T1 ), I have never tried it over a modem connection. It does jump arround a little, but is very useable. I have found that one of the best ways to improve it's performance is to have a background of one color. Get rid of the fancy wallpaper image, and make it one solid color.
Sig free since 2/6/2002
The Microsoft 16bit client provided on the WTS CD works marvelously under Wine. The 32 bit, I've never gotten to work, although I haven't tried with newer builds of Wine.
I did it once from my in-laws over a modem to show my father-in-law what kind of work we're doing - he was more impressed with VNC than my day job. Oh well...
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).
Vintage computer games and RPG books available. Email me if you're interested.
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:
As you can see, most major changes introduced in TightVNC are related to efficient bandwidth usage.
Okay, each of our branches had a 64k leased line, and depenfing on what branch a minimum of 3 or maximum of 12 computers on that leased line.
VNC we found was fine if you connected as 8 bit colour. Connecting through a web brower seemed faster than using the client.
Although I never used it, others did through RAS (so basically a 33k modem connection) to access other PCs at the head office. They said it was okay there too.
try to make ends meet, you're a slave to money, then you die
Actually, older versions of XWin32 are freeware (or shareware?). I trolled Google and found an old copy. Works great.
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. (Most serial console connections to sun/hpux boxen are static at 9600). If you want low latency, 33.6 is fast enough.
Your lag in 'pine' is probably based on the server and not the connection.
But who uses telnet anyway? You should be asking about ssh.
check out for yourself. The bandwidth/latency needed depends very much on what exactly you are doing, and how patient you are. Set it up on a local network with a traffic monitor, and see what kind of bandwidth it uses. If necessary throw it through a traffic shaper and play with it.
We have 10 remote sites and use VNC to admin well over 100 boxes via 56K frames. The speed is not too bad if you set to 8bit color(even on our 1300 mile frame.) But then VNC will use just about any amount of bandwith the you provide it. I've seen it suck up most of a 100mb connection.
>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. Protocol overhead? BS. It's the routing overhead that gets you. Your 2400 was a direct connection.
I read some posts about it, i never saw or used it, but i wonder can i connect to it with non MS clients ?
Although it is not fast, the speed of connecting to VNC is quite tolerable. One thing I do not like of VNC is its inability to shut off the Java http server, which is a security problem.
¦ ©® ±
You need to buy extra licenses from Microsoft to use Terminal Services, which you have to validate directly from them. If you use Terminal Services in Application Server mode, and don't get it approved by Microsoft, it stops working after 90 days.
b uy/pricing/terminal.asp
b uy/pricing/pricingwindows.asp#terminal
What you have to buy is TS-CALs.
TS-CAL's cost:
Windows 2000 Terminal Services CAL 5-pack $749
Windows 2000 Terminal Services CAL 20-pack $2,669
And if you want to connect over the Internet:
Windows 2000 Server Internet Connector License $1,999 Unlimited CAL licensing for Internet clients only.
Windows 2000 Terminal Services Internet Connector License $9,999
But please, don't believe me, observe these web pages!
http://www.microsoft.com/windows2000/server/howto
http://www.microsoft.com/windows2000/server/howto
Using Terminal Server in remote administration mode does not require extra licenses.
XFree86 and VNC do not have such licensing requirements.
I hope this post helps you decide what method of network application use you want to use.
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.
"Patriotism is your conviction that this country is superior to all other countries because you were born in it." -- GBS
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).
"Patriotism is your conviction that this country is superior to all other countries because you were born in it." -- GBS
yeah..member ddial that ran on the apple II, which top speed was 300 baud?!
now THATS the shit!
.kb
Two Wrongs Don't Make A Right-- But They Make Me Feel A Whole Lot Better
So I think my point is that it can be processor-intensive, too.
________________________________________________
________________________________________________
suwain_2
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.)
There is no America. There is no democracy. There is only IBM and AT&T and DuPont, Dow, General Electric, and Exxon
I've used the ARM VNC viewer on an iPAQ PocketPC to view a Win2K box over a 40k/sec HSCSD connection in the UK.
It was perfectly usable if you can tolerate lag. VNC over a 10Mb/s network is bad enough sometimes, but imagine it over a connection that has to traverse a cell and POTS before it even hits a router of any shape or form.
But adjust to the lag and it's golden.
Ryszard
- 'sup, G?
I can telnet on 56k and still be able to do PINE just fine. What really kills you is the lag time more then the bandwidth. Type in Q and wait .2 seconds to view it is not fun.
----
Just because a bunch of people believe or do something stupid, doesn't make it any less stupid.
Crashes on my computer after 10 minutes and the colors are messed up. Is it me or just my setup?
----
Just because a bunch of people believe or do something stupid, doesn't make it any less stupid.
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.
----
Just because a bunch of people believe or do something stupid, doesn't make it any less stupid.
I haven't seen this mentioned here yet, but i work a help desk in a medium size law firm (~200 win95 machines) and we use vnc to keep our asses planted instead of going to a user's desk to see the latest illegal operation. We have a 100mbit switched network, and vnc doesn't have any noticeable lag. The annoying part is having to force a screen refresh because illegal ops don't show on the remote screen unless you do.
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."
"Press any key to begin."
"AnyKey? Where's the AnyKey?" - Homer J. Simpson
I've been using VNC 3.3.3 for several months now and prefer it very much over pcanywhere. I have used it over a 56K modem line getting actual throughput of 40-43 K. Still works, even if it is slow. I didn't make any kind of tuning changes to it since it seemed to be working ok. Is this the kind of info you want ?