On 2/10/11 2:24 AM, Martin Koegler wrote: >> I really wonder how useful of a feature built-in session encryption is >> if it's this slow. Without encryption, I can get approximately 20 >> Megapixels/second. Tunneling through SSh, about the same. With TLSVnc, >> I get about 7.5 Megapixels/second. For my purposes, that's completely >> useless. > > Using TLSNone, I still get 20MBit in a local LAN. In my option, tight > encoding is worse (eg. skipping frams on the KDE splash screen) on > animations than eg. ZRLE.
What do you mean "still get 20 Mbit"? You mean Megapixels/second? Or do you mean Megabits/second of throughput? Because without VeNCrypt, my throughput is more like 50 Mbits/sec. It's 2.5x faster, roughly, with SSh (or no encryption) than with GnuTLS. I'm not the only one who has observed that GnuTLS is slow. Google 'gnutls openssl performance' and you'll see that others have observed a similar disparity. My workload is VirtualGL (remote 3D), and with 3D, it's pretty critical to maintain 15 frames/second or higher to ensure that the application feels interactive. Screen sizes of 2 Megapixels are becoming fairly common, so ideally what I want is 30+ Megapixels/second. I can get 35-40 with TurboVNC on modern hardware. With TigerVNC, I can nominally get about 30% less than that with encryption disabled, which is still quite usable. With VeNCrypt, however, it drops down to 7.5 Megapixels/second, which is too slow to be useful for doing any "real" work with 3D applications. I've been in the remote display business for well over a decade now, and I can tell you from experience that people just don't read documentation when they download software. They just download it, install it, and if it doesn't perform as they expect, they throw it out and never try it again. If TigerVNC is being billed as a high-performance version of VNC, then it needs to be performant by default. If it's being billed as a secure version of VNC, then it needs to be secure by default. Those two goals may not be mutually achievable. >> I am not comfortable shipping binaries with GnuTLS support if the >> out-of-box default behavior is 38% as fast as 1.0.1. I strongly believe >> that the server needs to re-order the default security types to be >> VncAuth, VeNCrypt, TLSVnc. In other words, the default out-of-box >> behavior would be the same as 1.0.1-- to use VncAuth if both ends >> support it. If someone is paranoid and wanted to use the much >> slower-but-more-secure VeNCrypt functionality as a default, they would >> need to specify -SecurityTypes when starting vncserver. Ideally, in the >> long term, this would be restricted by means of an authentication >> configuration file that the SysAdmin could use to force the use of only >> certain security types. > > VeNCrypt should be the first, so that tigervnc honors the security > type order. That seems like a circular argument. Please justify. >> If we leave things the way they are, users will think that our software >> has slowed down by more than 2X since 1.0.1. >> >> Further, these security types need to be documented. They are not >> mentioned in our man pages, and it is incredibly non-obvious what they do. >> >> Also, how does one enable user/password authentication? I see that in >> the options dialog, but it doesn't appear to correspond to a command >> line option. > > -SecurityTypes VeNCrypt,XXXPlain -PlainUsers XXXX OK, I got that working, now how do I get it working without session encryption? ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
