[K12OSN] VNCViewer and speed of refresh

[Jeff Kinz]

On Wed, Jul 14, 2004 at 01:38:17PM -0500, Les Mikesell wrote:
> On Wed, 2004-07-14 at 10:56, Jeff Kinz wrote:
> > X-windows works much better over low bandwidth links than VNC.
> > Why?   Raw Data vs. Abstraction
> 
> This depends very much on the screens involved.

Yes it does.
> 
> > Remote X-windows doesn't send any graphical information over the link.
> > It sends only events like "Close Window 27" to the X-server at your
> > display.
> 
> Perhaps if you are talking about xterms, but what's the point of

Who would run xterm over either VNC or X-Win when they can just ssh
into the system? 

In the scenario given above, (Close a window) the remote X-Win system
transmits only the event and the local X-server already knows everything
it has to do to update the display which it does at the speed of the
CPU/graphics card combo. As fast as the machine is capable of.

VNC, on the other hand - has to transmit a bit image of everything that
changed from the remote system running the application to the local
VNCviewer program that is drawing the bits on the screen. It is limited
by the speed of transferring the change images over the net.

Here XWin is much faster. In this case X-Win is sending less data by
orders of magnitude.

I used it to run GUI applets, mostly redhat config tools. 
Performing the same exact tasks, across the same internet connection,
using the same exact machines, a Local RH 7.2 system and a remote
K12ltsp server, VNC was incredibly slow and remote-X was almost snappy.

I ran VNC on a 800x600 screen and ran remote X on a 1600x1200
screen.  Even with that disparity the X sessions were much faster.

> How do you propose that mozilla might
> draw a picture on your remote screen without sending all the
> bits of the image?  

So in the case of a "new" picture image Both X and VNC pay almost the
same cost to transfer the image over the network connection because now
"both" are limited by the net transfer speed. 

> Now imagine an X program where the graphics
> change faster than they can be delivered to the remote (or
> try viewing an animation over a dialup...).

In this scenario IF the connection is not a low latency one, (Yeah, right
whose internet are you on? :)  ) VNC would have some advantage.

> > VNC, on the other hand, has to send an entire frame buffer of raster    
> > data (hopefully optimized), resulting in transfers of thousands
> > or tens of thousands of bytes where X sends only twenty or thirty bytes.
> 
> VNC can send whatever changed on the screen as it makes its scan and
> the program keeps going even if you just see choppy snapshots at
> the slow remote.  

Yes, thank god, otherwise VNC would be even worse. It works fine over a
LAN but any connection I've used it on over the internet was horrid.

In my last situation, 27 hops, 140 "air miles", 3 major networks (ATT, Sprint
and Southern Bell) latency was high. In fact I've noticed that almost
every connection I make over the internet is very similar to this in
terms of hops, no matter what the distance. Opposite coast or in same state
same cost to access it.  So no matter what I try to connect to its going
to be bad for VNC.    Maybe I need to get off comcast. :-)

> X has to wait and if the remote can't display
> as fast as the program is trying to generate the images it will
> just never work.
Hmm, I've haven't had this happen... so far..

> > Even with intelligently optimized 'skipping" of redraw data remote frame
> > buffer systems like VNC have to send much more information over the
> > network.
> 
> It takes about so many bits to represent an image any way you slice it.
> X can optimize internal things but if you are really displaying graphics
> there's not much it can do but push the bits.

Its starting to look to me like VNC might be faster when there is a low
latency connection to a highly dynamic visual application.

> 
> > If VNC is more efficient, then we should use it instead of an X server
> > for the thin clients right ?  Its certainly smaller than an X-Server.
> 
> No, VNC is always going to have more latency because it is only
> connected to the screen buffer and doesn't know which part the
> program wants to change.
Right.

> 
> > (( Historical Note - VNC was invented by some folks at Olivetti in
> > the UK (Later became part of AT&T). Its designed and intended use was
> > to permit people using very small systems, incapable of running an
> > "X-server", to access a machine running X-Windows.
> 
> Actually in the lab where it was invented they used it routinely
> on their desktops with a system that identified the users by their
> lab badges and as they approached any client machine it would
> automatically yank their running desktop session to them.

Yes, that was cool.
Now why can't we do that with the public machines in the airport?

Of course it must have sucked for the the single guys who were always 
hanging out by the desk of the only one or two single females in the
place.  Imagine the what trends the traffic analysis could reveal.. :)

-- 
Linux and Open Source.  The New Base.  

Now All your base belongs to you, for free.

Jeff Kinz, Emergent Research, Hudson, MA.