Please disregard my initial benchmarks. It turns out that my RHEL 6 server was dialing down the network speed to 100 Mbps (long story as to why.) I did a more apples-to-apples comparison using the CentOS 5.6 server in both cases, as well as the latest & greatest TigerVNC server code:
CentOS 5.6 server with RealVNC 4.1.2 --> Mac with TigerVNC 1.0.90 r4501 Hextile: ~6.1 Mpixels/sec, ~80 Mbps ZRLE: ~8.6 Mpixels/sec, ~35 Mbps Raw: ~15 Mpixels/sec, ~240 Mbps CentOS 5.6 server with TigerVNC 1.0.90 r4501 --> Mac with TigerVNC 1.0.90 r4501 Hextile: ~21 Mpixels/sec, ~285 Mbps ZRLE: ~12 Mpixels/sec, ~53 Mbps Raw: ~26 Mpixels/sec, ~460 Mbps Tight: ~31 Mpixels/sec, ~44 Mbps Also, my assertions about Hextile are apparently no longer valid with TigerVNC. Not sure what we've improved in that protocol vs. RealVNC, but it's considerably faster now than ZRLE. On 6/17/11 2:59 PM, DRC wrote: > YMMV, but some quick & dirty benchmarks from my systems are below. I'm > using a Mac as the client in both cases: > > CentOS 5.5 server with RealVNC 4.1.2 --> Mac with TigerVNC 1.0.90 r4501 > > Hextile: ~6.1 Mpixels/sec, ~80 Mbps > ZRLE: ~8.6 Mpixels/sec, ~35 Mbps > Raw: ~15 Mpixels/sec, ~240 Mbps > > RHEL 6 server with TigerVNC 1.0.90 r4359 --> Mac with TigerVNC 1.0.90 r4501 > > Hextile: ~7.0 Mpixels/sec, ~94 Mbps > ZRLE: ~10 Mpixels/sec, ~47 Mbps > Raw: ~6.2 Mpixels/sec, ~94 Mbps > Tight: ~27 Mpixels/sec, ~33 Mbps > > The RHEL 6 server is a slower machine, but even so, the TigerVNC server > was still faster than the RealVNC server when using Hextile or ZRLE. > > > Several observations: > > -- Not sure why Raw encoding is so slow in the TigerVNC server. We > should investigate that. > > -- Hextile, in general, sucks. I've heard spurious reports of people > who claim that it's faster in some cases, but personally, I have never > observed that. If you're communicating between TigerVNC and RealVNC, I > would recommend using ZRLE. Hextile is an incredibly "chatty" protocol, > because the tiles it uses are only 16x16 pixels. Thus, it is very > sensitive to latency and will become latency-bound even on a local-area > network. > > -- When using TigerVNC on both ends, Tight encoding is by far the > fastest option, even on a gigabit network. > > > Can you verify that the connection is not using session encryption > (GnuTLS)? That's the only thing I could imagine that could be causing a > slow-down. > > Also, could you try using the cross-compatible build from > http://www.virtualgl.org/DeveloperInfo/TigerVNCPreReleases on the > client, then, if that makes no difference, put it on the server as well? > > Also, it was unclear in your messages what version of vncviewer was > originally being used (before you tried replacing it with the TigerVNC > Viewer), and it was also unclear what protocol the clients were using > originally. If it was Raw, then that would explain the slow-down. > > > On 6/17/11 11:38 AM, Lorenzo Fiorini wrote: >> Sorry, I forgot to mention that in Centos 5.5 the vncserver was >> RealVnc and in Rhel6 it is tigervnc-server-1.090..svn4359.el6. >> >> best regards, >> LF >> >> ------------------------------------------------------------------------------ >> EditLive Enterprise is the world's most technically advanced content >> authoring tool. Experience the power of Track Changes, Inline Image >> Editing and ensure content is compliant with Accessibility Checking. >> http://p.sf.net/sfu/ephox-dev2dev >> _______________________________________________ >> Tigervnc-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/tigervnc-users ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Tigervnc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tigervnc-users
