VNC quite slow ...

Jonathan Morton chromi "at"
Tue, 22 Aug 2000 13:15:16 +0000

>Better still, use a command line FTP transfer and it will tell you the
>transfer time and average transfer speed.  The basic question remains
>though; is this a performance issue on one of the machines (server and/or
>client) or is it a network issue (bandwidth/routing etc).
>Let's assume this is a system performance issue.  From the original post in
>this thread, it seems the Linux machine is the VNC-server and is being
>connected to by the Wintel box.  In my experience, if you are already
>running an X server on the Linux end and then start Xvnc (the VNC server)
>the RAM available falls through the floor - but that was only on 128Mb RAM
>on Linux.  However, when I kicked XFree86 out of the equation it was quite a
>lot faster.
>If on the other hand this is a network issue, there are a few things you can
>to try and isolate the performance problem.  Try a ping to the opposite
>machine and see if the times are sub 10ms (for a LAN, even through
>routers/firewalls this is pretty standard ping times).  Do a traceroute
>(from Linux) an a tracert from NT to the opposite machine - make sure it
>isn't routing via the Internet or any other networks, it should be as direct
>as possible in a well configured network.  If you think you've found a
>network problem have a chat with network engineering/network admin and see
>if they can solve the prob for you.

Since the two machines involved are quite powerful, I would suspect the
network unless lack of RAM was an issue.  Ping times are the most
significant factor for a VNC session, as they determine the latency (or
"lag").  However I have seen the following effect which might be worth

Connecting my fastest machine (PowerBook G3 mk4 400MHz) to my slowest
machine (486DX/25, Linux, 'recent' Xvnc) via a LAN, the rapid sequence of
FrameBufferUpdateRequests sent by the Mac completely bogs the 486 down, to
the point where 15 seconds or more can elapse before the mouse cursor is
seen to move on the framebuffer.  Putting the viewer into the background
(so that it gets less CPU time) causes a fairly immediate reduction in CPU
usage on the 486 and decreases latency by a large factor.

I suggest, on the Linux server, checking the amount of CPU usage, the load
averages, and the amount of swapping in progress.  This can be easily done
with the xosview program (which I use a custom script to start on my

[chromi "at" helium bin]$ cat xos

xosview -title xOSview -geometry 250x400+0-35 +net -networkBW 100000
-pagespeed 1000 -xrm xosview*loadPriority:50 -xrm
xosview*loadAlarmThreshold:4 -xrm xosview*cpuPriority:50 -xrm
xosview*memPriority:50 -xrm xosview*swapPriority:50 -xrm
xosview*pagePriority:50 -xrm xosview*netPriority:50 -xrm
xosview*diskPriority:50 -xrm xosview*diskBandwidth:100000 &
[chromi "at" helium bin]$ ls -l xos
-rwxr-xr-x   1 chromi   chromi        366 Aug 22 13:09 xos

The effect of this script is to 'slow down' xosview so that it gives more
useful information and avoids hogging CPU or X-server bandwidth.  The
various values involved (especially the geometry and bandwidth factors) can
be adjusted to taste.


from:     Jonathan "Chromatix" Morton
mail:     chromi "at"  (not for attachments)
uni-mail: j.d.morton "at"

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from

Version 3.12
GCS$/E/S dpu(!) s:- a19 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+
To unsubscribe, send a message with the line: unsubscribe vnc-list
to majordomo "at"
See also: