Ugh. OK, so this was due to VeNCrypt. It is apparently enabled by default if both server and viewer support it. I do not like that at all. It's particularly problematic because, once enabled, there is no way to subsequently disable it without disconnecting and reconnecting (the VeNCrypt boxes in the options dialog are all grayed out once the connection has been established.)
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. 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. 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. On 2/9/11 6:25 PM, DRC wrote: > When attempting to test the latest build (r4280) running from Linux > server to Linux client, I am seeing very poor performance, about half of > what I can achieve with 1.0.1 using identical settings. It appears to > be an issue with Xvnc, because replacing Xvnc with Xvnc 1.0.1 brings it > back to normal. Switching out VNCViewer doesn't seen to matter. I also > tried it without the patch I checked in recently to improve JPEG > performance (r4259), and no effect. Also tried increasing the JPEG > compression buffer (no effect.) Also verified that both ends of the > connection are using SIMD extensions. > > An unrelated issue is that whenever I try to use the vncviewer GUI to > set the Zlib level to something other than the default, the server > crashes (the log says "ZlibOutStream: deflate failed".) > > DRC ------------------------------------------------------------------------------ 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
