We may need to look at the break point between paletted and JPEG Tiles. It's possible that the server is trying to use JPEG for color depths that are too low, which is why the browser is taking a long time to repaint.
The VNC protocol is fundamentally bad for high-latency connections, because it is client-driven. Thus, a full round trip has to take place between client and server for each framebuffer update. I'm not sure what the latency of your connection is, but if it is particularly high, then this may dominate your performance moreso than bandwidth. I will say that TigerVNC is not tuned for connections that slow. Tuning the protocol to be exceptionally "tight" on very low bandwidth connections makes it perform miserably slow on faster connections. However, I think there is still probably room for improvement. I can't comment on the auto detection code, since I didn't write that. I did extensive studies with TurboVNC to find the appropriate balance between "tightness" and speed. I would like to do the same studies with TigerVNC, but currently I am looking for financial sponsorship for this work. [email protected] wrote: > Hi, I've split from earlier discussion entitled tigerVNC configuration > problems > > to recap , I call the viewer within a secure shell on the remote machine: > > ssh -C -X -L 5900:localhost:5900 remotesys.dyndns.info > vncviewer localhost:0 > > Both ends are recent linux. Tigervnc was built from source on remote > Kubuntu 9.04 system using kubuntu xorg source tree and tigervnc-1.0.0 > tar.gz > > > technically it seems to work fine but it is very slow. > > > On 02/24/10 21:38, DRC wrote: >> [email protected] wrote: >>> Thanks, that is what I would expect to be the case but without -C it is >>> about an order of magnitude slower! Completely unusable. I had to break >>> the viewer from its command line. >>> >>> Would that suggest that there is no jpeg compression happening? >> >> Hmmm... Weird. Again, try explicitly dialing in a lower quality level. >> I struggle to imagine how SSh could further compress a JPEG stream, but >> maybe if the JPEG quality is high enough it can. >> >> > > 1. autodetection not working > > man vncviewer: > > AUTOMATIC PROTOCOL SELECTION > The viewer tests the speed of the connection to the server and > chooses > the encoding and pixel format (color level) appropriately. This > makes > it much easier to use than previous versions where the user > had to > specify arcane command line arguments. > > > No this is not working. Connection information shows typically 20000 > kb/s , the remote end is 300kB/s connectivity , local end is only 88kB/s > at best , currently only 40kB/s . > > Is the auto detection effectively testing the connection to localhost > when run in this context? > > > > 2. There does not seem to be a documented option ot turn off jpeg > compression. > > > 3. Any format on an uncompressed ssh link is UNUSABLY slow. Each half > inch line of screen update is taking about 5-6 seconds. It takes > several minutes to fill initial window and respond to an F8 keystroke. > > 4. Option dlg unclear about "custom" compression and jpeg compression. > Are these alternative expressions of the same setting? If not what is > "custom". Does it to ZRLE? There does not seem to be any doc on what > this does set nor any command line option to which it may seem related. > > > 5. After some experimenting using the Options settings available from F8 > in the vncveiwer running through a COMPRESSED ssh link. > > ZRLE was fastest, Tight jpeg Q9 was about same a raw, any other jpeg > quality was slower jpeg Q1 was more than twice as slow as Z . > > Test condition was rather trivial: opera browser full screen on remote. > After changing compression , a new brower page was loaded to ensure > server recomposed most of the screen. Initial display was even slower . > Test was the time to refresh Tigervnc window after collapsing it to it's > title bar and redisplaying. > > > I would have expected using vnc compression options on uncompressed link > to be similar (+/- 50%) to using compressed link. I would expect using > both vnc and -C to be slower. In fact using -C is essential to have some > resemblance of a useful link. > > > Any advice on making this more functional would be appreciated. > > Thanks again. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Tigervnc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tigervnc-users
