Oh, also: If you -are- seeing wifi bandwidth saturation, it could - yield- a CPU overload, because the VNC protocol attempts to dynamically adjust how hard it compresses data to best utilize the available bandwidth. On a really fast link, VNC might not compress at all, and on a really slow link, VNC might think really hard about how to do the hardest compression it can. So VNC might start out using minimal compression, but then as the bandwidth starts getting saturated due to all the VNC sessions using sparse encodings (not compressed that hard), the CPU time spent on compression might go up quite a bit. > I'm guessing that RealVNC is bogging down your laptop because: > > 1) It's an older, slower laptop > 2) Each vncviewer instance is making the VNC server re-compress > essentially the same data again and again > > You may be able to resolve this difficulty by: > > 1) Using a faster server > 2) Using fewer vncviewer's > 3) Evaluating some software to tune up the process, listed below > > Candidate software you might want to evaluate: > > 1) http://www.linux-in-der-schule.de/vnc-eye/ (in German, but > babelfish is your friend) > 2) http://www.sd.no-ip.biz/code/vncmux/ > 3) http://sourceforge.net/projects/vnc-reflector/ > 4) http://www.gnome.org/~markmc/a-look-at-nomachine-nx.html > (comes with Damn Small Linux, I gather, and probably SuSE as > well. It's also likely more for low bandwidth situations, > more than low CPU situations) > > Another possibility might be to tune your VNC sessions to use JPEG > compression (they may be using it already), but then also tell them to > use a faster/more lossey JPEG compression. > > Also, if you're finding the bandwidth is getting saturated by lots of > wifi traffic (a distinct possibility, I imagine, if you have lots of VNC > sessions running over it), you may be able to tweak your access point to > use smaller packets (I have some other tweaks that might help too, if > you're into this sort of thing), or switch to 802.11g or 802.11a or > something - or even string some 100BaseT cables.... > > Finally, I've had some success running a vncviewer under a vncviewer... > So if you first contend with any possible bandwidth saturation problems, > then you might be able to alleviate CPU load problems by doing a sort of > binary tree fanout of VNC sessions, like: > > server with original data > / \ > client+server client+server > / \ / \ > client+srvr clnt+srvr clnt+srvr clnt+srvr > > ...and so on. This should greatly reduce the CPU load on the top-level > server, at the expense of more wifi (or 100BaseT?) bandwidth > consumption. This should reduce the load on any given machine to at > most 2 clients and one server process. > > Oh, one more thing: If you aren't pushing highly detailed images, then > you might be able to cut both bandwidth and CPU usage, by reducing > screen resolution on the server and clients, or leaving the resolution > alone on the server but using the server-side-scaling that I believe is > present in one or more windows VNC servers, and then cut the resolution > on the clients only. > > Thanks! > > > ...In looking at all the suggestions, > > and considering cost, we used the RealVNC Open Source software to get > > the job done. The problem we ran into was that the RealVNC server app > > on our stats laptop slowed down the system to the point that it > > affected the recording of the stats, especially when more than one > > system was connected (we wanted to see the screen in another building > > as well). So I am looking at a solution that will allow us to scale to > > multiple RealVNC clients w/o affecting the statisticians.
You can e-mail the author with questions or comments: