zlib compression on local LAN?

[Greg Breland]

The slowdown IS caused by VRAM -> CPU bottleneck, but the author did not say
WHY this is the bottleneck.  On Windows machines, the VNC server has to poll
the video buffer to see if any part of the screen has changed and needs
updating.  This is a VRAM -> CPU operation.  Try disabling polling
completely.  If you look at your CPU usage while VNCed into your machine,
the CPU usage will be 80% or so.

Don't think VNC is bad because it works this way.  Other programs get around
this problem by replacing a lot of DLLs on your system with their own, which
causes unstability.  VNC is the best program for remote access of Windows
servers because it runs in its own memory space and will not bring your
server down.

Greg

> -----Original Message-----
> From: Kelly F. Hickel [mailto:kfh "at" mqsoftware.com]
> Sent: Thursday, June 29, 2000 8:16 AM
> To: 'vnc-list "at" uk.research.att.com'
> Subject: RE: zlib compression on local LAN?
> 
> 
> Jonathan,
> 	Thanks for your response.  I'm following up because I 
> should have
> mentioned that both machines in this case are running windows 2000.
> 
> -Kelly
> 
> -----Original Message-----
> From: Jonathan Morton [mailto:chromi "at" cyberspace.org]
> Sent: Thursday, June 29, 2000 8:10 AM
> To: vnc-list "at" uk.research.att.com
> Subject: Re: zlib compression on local LAN?
> 
> 
> >Hi All,
> >	Does anybody have any opinion (HA!) as to using zlib 
> compression on
> >a local LAN?  I have two fast machines that are connected by 
> a 100mbps
> >switch on my desk.  I've noticed that when one is vnc'ing 
> the other that
> the
> >server machine's screen updates slow noticeably.  Now, I 
> understand that
> >this is because I'm inserting a network operation into the 
> video stream,
> so,
> >of course it's going to slow down.  My question is, Do you think the
> >slowdown is primarily CPU bound (catching the update, 
> hextile'ing it, etc)
> >or is it network latency?  Since these are fast machines, 
> I'd hope (but am
> >to lazy to try right now!) that the CPU overhead of the zlib 
> compression
> >would impose a lesser load on screen updates than the 
> network transmission
> >does.
> 
> It's more likely to be the server being slowed by an 
> inefficient VRAM->CPU
> transfer rate, as is found in many PC-type graphics systems (CPU->VRAM
> being much more heavily optimised).  Zlib normally introduces _more_
> latency on fast LAN networks, due to the added CPU overhead 
> compared to the
> virtually non-existant network latency itself.
> 
> Also, try switching off Hextile and use RRE, CoRRE et al 
> instead - Hextile
> can sometimes be slow to decode, although it is very fast and 
> efficient to
> encode.
> 
> --------------------------------------------------------------
> 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.
> 
> Get VNC Server for Macintosh from http://chromatix.autistics.org/vnc/
> 
> -----BEGIN GEEK CODE BLOCK-----
> 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+
> -----END GEEK CODE BLOCK-----
> ---------------------------------------------------------------------
> 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
> ---------------------------------------------------------------------
> ---------------------------------------------------------------------
> 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
> ---------------------------------------------------------------------
---------------------------------------------------------------------
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
---------------------------------------------------------------------