On Thu, Feb 10, 2011 at 04:40:13AM -0600, DRC wrote:
> 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

I mean the value showen in the viewer info dialog. What tools are you using?

> 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'm using Tigervnc (and had developeed it) for accessing normal
desktop in a secure way on Windows/Linux. In my option, VenCrypt
encryption works for this use case.

Video / 3D are a different use case, which requires optimisations
(eg. there is even an optimized version of libjpeg). gnutls is used
with its default settings and I have not looked, how TLSOutput stream
blocks the data into packets and when the data is flushed to the
network. For your usecase, such analysis are probably necessary.

> >> 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.

See my other mail: VeNCrypt is a chooser and if it is not on the first position,
a effective order is different.

The client should have all security types enabled by default (as
currently). I have no objections to modifying the list of default
security types in the server.

> >> 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?

Plain is also available without any encryption, but not enabled by default.

Regards,
Martin Kögler

------------------------------------------------------------------------------
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

Reply via email to