Client/Protocol feature question

[Jonathan Morton]

>At 19:36 07/02/2000 +0000, you wrote:
>
>>The most significant bandwidth-usage improvements, I think, are:
>>1) client double-buffering
>
>Absolutely - on 'resource unlimited' clients, I can't see any good reason
>not to do this.  I think the X client is the only one which doesn't do this.

And the Java one.  Provided there is enough free system RAM to hold the
server's screen, double-buffering is an immense speedup.


>>2) intelligent server (scan to see if area is really different or not)
>
>The WinVNC server does lots of that!  That's the problem!  Before you get
>anywhere near any VNC encoding or transmission, the screen image has been
>compared with a buffer to see if it's 'really different or not'.  It's this
>process which is slow, not the subsequent encoding of the data which has
>changed.  There is little that can be done to optimize this on the PC with
>the current message-hook hinting technique.  It's already limited largely
>by the poor screen-to-sysram transfer rate inherent in current PC video
>architectures.

I think you've hit the nail on the head there - PC video is very much
optimised for CPU-to-GFX transfers rather than the other way round.  Also,
I don't know how the WinVNC server works at the lowest level, but there
could be some 'inefficient' but necessary code in there - for example
blitting every updated window to RAM before checking it over.


>>3) new codecs (PNG etc.)
>
>Quite possibly valuable where the comms is an issue.

Which is why I suggested it at the same time as saying that LESS
cpu-intensive methods were better on LANs.  :)


>What most of the proponents in this discussion (myself included) lack is a
>decent set of numbers to go with some of these theories.

Quite true.  This needs serious study...


>  A lot of the
>discussion about the bits that should be speeded up is centred around
>things which are not currently the pinch-points.   All the platform and
>comms configurations have different pinch-points, anyway, which makes it
>particularly difficult.

Exactly.  There are a number of uses for VNC, each with their own demands
on particular types of hardware - hence my suggestion of a modest extension
to the protocol to help optimise the connection for the hardware available
(modem/LAN, 486/Sparcv9, etc).  I am also all too aware of the differences
between platforms, for starters they look different and so place different
demands on the various codecs in use, and then they have differing OS
architectures which are more/less helpful about giving out information.

Personally I think the WinVNC implementation is making the best of a bad
job.  It is having to work in a severely limited environment, and I think
the developers deserve a pat on the back for their ingenuity :).


>I, too, am skeptical about the value of checksum-based caching.  But that's
>because it doesn't solve any of the problems I see. (I think it would
>exacerbate them.)  But maybe it's right elsewhere.

Hmmm...  quick case-study time I think.  Say you are trying to improve
latency over a modem-link across the Internet (an extreme example but it
frequently happens).  You start by trying to reduce the amount of data that
needs to be sent, so you scan the server-data for redundancy and implement
double-buffering on the client.  Then you find the scanning is taking too
long on the server (WinVNC in this case), so you look for ways to improve
that - checksumming?

If the client keeps hold of a cache of tiles, with checksums attached, then
suppose the client doesn't have a tile cached?  The server sends the
checksum out (after laboriously calculating it) which takes, say 300ms to
reach the client (typical Internet lag between UK and Silicon Valley).  The
client does a quick scan of its database, doesn't find it, and then
transmits the request all the way back, taking a further 300ms.  So we have
a total 600ms of extra latency introduced, during which a modem operating
at (say) 40,000 bps could transfer nearly 2.5 Kb, sufficient to draw a
reasonably sized piece of screen.  The likelihood of any sanely-sized cache
holding any given tile that could not be eliminated by the server's
scanning process itself... is pretty small.  Therefore, checksum caching is
a Bad Idea.  QED.


Actually, I have a further suggestion for the WinVNC team.  Instead of
regularly polling the entire screen, why not poll random small segments at
more frequent intervals?  If an update is found that way, you could then
scan surrounding segments as these are more likely to have changed.  Just a
thought :).

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

The key to knowledge is not to rely on people to teach you it.
--------------------------------------------------------------
Contributing to the VNC Project - http://www.uk.research.att.com/vnc/
Ask me for Macintosh VNCserver v3.3.2 beta2.1
v3.3.2 beta 2.2 due out soon!



---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to majordomo "at" uk.research.att.com
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------