120 ms is enough to ensure that no more than 4 updates per second reach the client (1 / (2 • 120 ms)). The defer update mechanism is critical to ensuring these updates are as large as possible, as you already determined. Unfortunately, I couldn't determine by looking at the source whether or not this mechanism is implemented in the module or how to configure it. Hoping someone else on the list knows.
On Feb 25, 2010, at 3:52 PM, ti...@piments.com wrote: > 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. >> >> ti...@piments.com 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: >>>> ti...@piments.com 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 Tigervnc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-users
