On 02/25/10 20:31, DRC wrote: > 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. > here's a snip from a traceroute. It ain't fast but is there anything you would see as accounting for chronic slowness?
8 tiscali-1.GW.opentransit.net (193.251.254.22) 55.433 ms 60.919 ms 63.030 ms 9 xe-10-2-0.lon20.ip4.tinet.net (89.149.185.210) 75.652 ms xe-10-3-0.lon20.ip4.tinet.net (89.149.184.45) 78.244 ms xe-10-2-0.lon20.ip4.tinet.net (89.149.185.210) 83.232 ms 10 tiscali-uk-tch1.ip4.tinet.net (213.200.77.178) 86.469 ms tiscali-uk-gw2.ip4.tinet.net (213.200.79.186) 89.581 ms tiscali-uk-tch2.ip4.tinet.net (213.200.78.234) 94.195 ms 11 ge0-0-0.he-lon0.as9105.net (212.74.106.53) 97.432 ms 102.172 ms * 12 ge1-1-0-26.bhm-1-dsl.as9105.net (212.74.106.173) 119.774 ms 121.006 ms 125.967 ms 13 * * * > 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 think this is bigger than just a case of sub-optimal tuning. I'll resume my findings from earlier: ssh -C 265 colours = a bit slow but workable ssh -C 24 bit colour = functional but annoyingly slow ssh any color depth = absolutely unusably slow , even for debugging purposes Within a factor of 2 all compression options, including raw, are about equal on ssh -C Apparently, ssh is managing to very significantly compress something that tiger is missing. One anomaly that may be significant is the image size. Size: 1366 x 1366 If I go fullscreen I get the full image height within my 1024 x 768 client screen but with a large black area below that I can scroll to. So for some reason the server is transmitting a large square rather than the true desktop image. Can you suggest any reason for that ? Thanks. > 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
