Re: [Tigervnc-devel] Severe performance problem and possible Zlib issue with r4280
On Sun, Feb 13, 2011 at 04:32:46PM -0600, DRC wrote: So what exactly is a default Linux installation? I don't think anyone can reasonably conclude that what is true for their Linux installation is true for all Linux installations. The performance problems are triggered by running running high performance applications like virtualgl, which is not part of any major distribution]. So any user of default installation of a major linux distribution has either an Xvnc without 3D support or is limited by the software renderer - they will not hit your test case. I still don't fully buy that OpenGL isn't causing some amount of CPU overhead that may still be limiting the frame rate, but I agree that a 2D frame flipping benchmark would be a better test. The overhead is the same for None or TLSNone, as OpenGL is drawing into the frame buffer - TLS only affects the data transfer between Xvnc and vncviewer. In the meantime, let's make the assumption that neither one of us is mistaken and that there really is a difference in how our systems are performing with GnuTLS. The only explanation I can come up with for that is that our versions of GnuTLS were built differently. Perhaps there is some performance feature that is enabled in yours but not mine? I've tried building against the GnuTLS chain that is on RHEL 4, as well as downloading the latest greatest (GnuTLS 2.10.4) chain and building it from source, and I get identical results. I'm only using the precompiled libraries from my Debian distribution. They all should have been upgraded to Squeeze, but I can't guarantee, that there is something left from an older releases. When you are running your tests, are you using the binaries I built and uploaded, or are you using your binaries, which are presumably built against the system installation of GnuTLS? If you haven't tried my binaries, please try them. That will tell us whether the above hypothesis is correct. I have downloaded your 64 bit binaries, but can not test, as Xvnc does not support the GLX extension [(EE) AIGLX error: dlopen of /tmp/tigerbuild.c27921/tigervnc-1.0.90/linux64/xorg.build/lib/dri/swrast_dri.so failed]. Also, I was using TLSVnc, not TLSNone, but that shouldn't make a difference, right? Yes, this should not make any difference - TLSVnc only adds the password exchange, but after that, the protocol is the same. 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
[Tigervnc-devel] [ tigervnc-Bug Tracker-3178498 ] ScaledPixelBuffer::setSourceBuffer() does not work for me
Bug Tracker item #3178498, was opened at 2011-02-11 19:06
Message generated for change (Settings changed) made by atkac
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1126848aid=3178498group_id=254363
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jochen Tucht (jtuc)
Assigned to: Adam Tkac (atkac)
Summary: ScaledPixelBuffer::setSourceBuffer() does not work for me
Initial Comment:
common/rfb/ScaledPixelBuffer.cxx
@@ -78,1 +78,1 @@
- if (w 0 h 0 src_data != NULL) {
+ if (w 0 h 0 src_data_ != NULL) {
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1126848aid=3178498group_id=254363
--
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
[Tigervnc-devel] [ tigervnc-Bug Tracker-3178498 ] ScaledPixelBuffer::setSourceBuffer() does not work for me
Bug Tracker item #3178498, was opened at 2011-02-11 19:06
Message generated for change (Settings changed) made by atkac
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1126848aid=3178498group_id=254363
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: trunk
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Jochen Tucht (jtuc)
Assigned to: Adam Tkac (atkac)
Summary: ScaledPixelBuffer::setSourceBuffer() does not work for me
Initial Comment:
common/rfb/ScaledPixelBuffer.cxx
@@ -78,1 +78,1 @@
- if (w 0 h 0 src_data != NULL) {
+ if (w 0 h 0 src_data_ != NULL) {
--
Comment By: Adam Tkac (atkac)
Date: 2011-02-14 15:21
Message:
Thanks for report, fixed in r4289.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1126848aid=3178498group_id=254363
--
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
Re: [Tigervnc-devel] Integration work completed
On 2/14/11 4:52 AM, Adam Tkac wrote: I successfully use CMake Visual Studio 2008 Express to build all Windows stuff with all features. And I'm also using MS VStudio for debugging testing on Windows. I will extend BUILDING.txt with information how to build GNUTLS support on Windows. However for development I prefer to use MinGW autotools because it's easier for me to develop on my Linux workstation and use wine for basic testing. I would prefer to keep autotools scripts for windows version. However I agree to mark autotools scripts for Windows as obsolete. Can't you use CMake to cross-compile on Linux as well? You should be able to. I would really like to see everyone who is currently using autotools on Windows switch to CMake, because that means more sets of eyes will be regularly looking at the build system that we officially support, and we are more likely to catch problems with it. -- 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
Re: [Tigervnc-devel] Patch to integrate libssh
On 2/14/11 5:42 AM, Adam Tkac wrote: I see a couple problems with this solution: 1. This method still closes the socket after identifying a port, which would allow the port to be allocated again before /usr/bin/ssh finally gets around to opening the forwarding channel and binding to the local port. A second vncviewer process started in close proximity is admittedly *less* likely to choose that same port, but the possibility still exists. The likelihood would be a function of how the operating system assigns ephemeral ports, which is certainly platform dependent and hard to predict. 2. The port number you'll end up with is an ephemeral port. Although explicitly binding to and listening on an ephemeral port is certainly allowed by ssh, it is also a little unconventional. DRC's patch seems like better approach for me than integration with libssh. However I would extend the patch a little. After we successfully bind(3) a socket then we can spawn /usr/bin/ssh. We can probably use exec*(3) instead of system(3) call and check if ssh was able to bind the port. If not then we can try to find another free port spawn ssh again. For example 20 times by default. It's right in theory SSH tunnel estabilishment might still fail but in practise it won't happen. What is your opinion about this proposal? I've been using the scheme represented in the patch quite successfully with VirtualGL for years. In VirtualGL's case, the free port has to be obtained on the server side, not the client side, so there is much more risk of conflict, but none has ever been reported. I don't understand how, even in theory, establishing the SSH tunnel would fail unless you were trying to launch thousands of vncviewer processes at once (and there are likely to be other failures with that.) Each time you bind the port, the ephemeral port counter is incremented by 1, so even if another vncviewer process tries to bind a port between the time the first process bound its port and launched ssh, then it would still succeed. Keep it simple. Fix and test the problem at hand. If we go off trying to solve theoretical problems that don't yet exist, we may end up creating new real problems. -- 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
Re: [Tigervnc-devel] Severe performance problem and possible Zlib issue with r4280
On 2/14/11 2:25 AM, Martin Koegler wrote: The performance problems are triggered by running running high performance applications like virtualgl, which is not part of any major distribution]. So any user of default installation of a major linux distribution has either an Xvnc without 3D support or is limited by the software renderer - they will not hit your test case. I disagree. I think there is something system-specific that is occurring and that you would be observing this problem very plainly if you were using my system. Others on different systems may run into it as well. We need to figure out what's going on. I have downloaded your 64 bit binaries, but can not test, as Xvnc does not support the GLX extension [(EE) AIGLX error: dlopen of /tmp/tigerbuild.c27921/tigervnc-1.0.90/linux64/xorg.build/lib/dri/swrast_dri.so failed]. OK, let me see if I can get you a 2D benchmark to use. In the meantime, can you tell me how the GnuTLS/libgcrypt/libtasn1/libgpg-error libraries are built on your Linux distribution-- specifically, whether any special configure flags were used? -- 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
Re: [Tigervnc-devel] Patch to integrate libssh
On Mon, 14 Feb 2011 14:07:17 -0600, DRC wrote:
On 2/14/11 5:42
AM, Adam Tkac wrote:
I see a couple problems with this solution:
1. This method still closes the socket after identifying a
port,
which would allow the port to be allocated again before
/usr/bin/ssh finally gets around to opening the forwarding channel
and binding to the local port. A second vncviewer process started
in
close proximity is admittedly *less* likely to choose that same
port, but the possibility still exists. The likelihood would be a
function of how the operating system assigns ephemeral ports,
which
is certainly platform dependent and hard to predict.
2. The port
number you'll end up with is an ephemeral port. Although
explicitly
binding to and listening on an ephemeral port is
certainly allowed
by ssh, it is also a little unconventional.
DRC's patch seems
like better approach for me than integration with
libssh.
However I would extend the patch a little. After we successfully
bind(3)
a socket then we can spawn /usr/bin/ssh. We can probably use
exec*(3)
instead of system(3) call and check if ssh was able to bind
the port.
If not then we can try to find another free port
spawn ssh again.
For example 20 times by default. It's right in
theory SSH tunnel
estabilishment might still fail but in practise it
won't happen.
What is your opinion about this proposal?
Do you
know of a way to check for the successful bind? One of the behaviors
that drove me down the libssh path was that /usr/bin/ssh happily
continues running despite failing to bind to the local port. Therefore
there is no exit status to interrogate for success/failure. Can you
think of a different way to check for successful bind?
I've been
using the scheme represented in the patch quite successfully
with
VirtualGL for years. In VirtualGL's case, the free port has to be
obtained on the server side, not the client side, so there is much
more
risk of conflict, but none has ever been reported.
I don't
understand how, even in theory, establishing the SSH tunnel
would fail
unless you were trying to launch thousands of vncviewer
processes at
once (and there are likely to be other failures with that.)
Each time
you bind the port, the ephemeral port counter is incremented
by 1, so
even if another vncviewer process tries to bind a port between
the
time the first process bound its port and launched ssh, then it
would
still succeed.
You're making an assumption about how the operating
system assigns ephemeral ports (the +1 counter). There isn't any
specification (at least that I'm aware of) that dictates how this
assignment should work, or even what range of ports should be used. I
have witnessed different behavior on different operating systems. Like I
said earlier, you're certainly greatly reducing the likelihood of a
conflict, but not truly addressing the issue. As soon as you close the
bound socket, you're releasing the port number back into the wild and
opening up the possibility of conflict. In my experience, the 1% error
case always bites you the first day you deploy to a mission-critical
system...
Keep it simple. Fix and test the problem at hand. If we go
off trying
to solve theoretical problems that don't yet exist, we may
end up ve the immediate port problem, but I was also trying to be
proactive about other things, namely performance (eliminating another
process and another socket connection when using an SSH tu
tability
('system(/usr/bin/ssh -blah -blah -blah sleep 20)' isn't a portable
tunnel implementation).
If the license of libssh is not compatible,
then that's certainly a tangible argument against the integration.
libssh is delivered with both an LGPL and BSD licenses, though, which I
thought were at least as open as TigerVNC's GPL license.
--
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 th
=http://p.sf.net/sfu/intel-dev2devfeb;http://p.sf.net/sfu/intel-dev2devfeb
___
Tigervnc-devel
mailing list
Tigervnc-devel@lists.sourceforge.net [1]
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[2]
Links:
--
[1] mailto:Tigervnc-devel@lists.sourceforge.net
[2]
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
--
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
Re: [Tigervnc-devel] Severe performance problem and possible Zlib issue with r4280
This is an annoying problem I ran into when I was building and distributing to a couple of machines. Using the build-xorg scripts, it leaves the path hard set to the location of the xorg libraries/modules instead of setting a path and installing them to it with the main tigervnc program. Because these are runtime dynamic load libraries, you do not see an error until you attempt to run the server with those extensions enabled. A quick fix for your testing would be to get the /tmp/tigerbuild.c27921/tigervnc-1.0.90/linux64/xorg.build directory from DRC and extract it to the same path. I would like to find a more permanent way to fix this problem but it should only be an issue on distributions that have a version of xorg too old to build the Xvnc program against it... On 02/14/2011 03:35 PM, DRC wrote: I have downloaded your 64 bit binaries, but can not test, as Xvnc does not support the GLX extension [(EE) AIGLX error: dlopen of /tmp/tigerbuild.c27921/tigervnc-1.0.90/linux64/xorg.build/lib/dri/swrast_dri.so failed]. -- Robert Goley FOSS Implementation Specialist Toll Free: (800) 338-4984 Local: (770) 479-7933 Fax: (770) 479-4076 www.openrda.com America's only Free Open Source fund accounting software company. -- 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
Re: [Tigervnc-devel] Patch to integrate libssh
On 2/14/11 4:02 PM, Eric Stadtherr wrote:
Do you know of a way to check for the successful bind? One of the
behaviors that drove me down the libssh path was that /usr/bin/ssh
happily continues running despite failing to bind to the local port.
Therefore there is no exit status to interrogate for success/failure.
Can you think of a different way to check for successful bind?
If it's not returning a failure status, then I'm not sure how it could
be done.
You're making an assumption about how the operating system assigns
ephemeral ports (the +1 counter). There isn't any specification (at
least that I'm aware of) that dictates how this assignment should work,
or even what range of ports should be used. I have witnessed different
behavior on different operating systems. Like I said earlier, you're
certainly greatly reducing the likelihood of a conflict, but not truly
addressing the issue. As soon as you close the bound socket, you're
releasing the port number back into the wild and opening up the
possibility of conflict. In my experience, the 1% error case always
bites you the first day you deploy to a mission-critical system...
I've been successfully using this type of port finding mechanism for
years with VirtualGL. It works solidly on Linux, Solaris, and Windows,
at least. The round robin ephemeral port assignment may not be part of
the spec, but it is the de facto behavior of modern operating systems.
I'd be curious to know what O/S's you're referring to that don't behave
in this way. I also don't understand why you can't thoroughly test it
on your specific configurations rather than argue a purely theoretical
case against it. You seem to have not even bothered to test the code
and see if it addresses the problem.
Even from a theoretical point of view, if we know that the operating
systems you plan to deploy on use round robin ephemeral port assignment,
can you conceive of any failure mode in that case? I can't.
I agree that libssh does more than solve the immediate port problem, but
I was also trying to be proactive about other things, namely performance
(eliminating another process and another socket connection when using an
SSH tunnel) and portability ('system(/usr/bin/ssh -blah -blah -blah
sleep 20)' isn't a portable tunnel implementation).
If the license of libssh is not compatible, then that's certainly a
tangible argument against the integration. libssh is delivered with both
an LGPL and BSD licenses, though, which I thought were at least as open
as TigerVNC's GPL license.
You're misunderstanding. The issues were:
(1) I was concerned that libssh would not perform well if it had to rely
on GnuTLS (I am still unable to get decent performance with GnuTLS,
although Martin is unable to reproduce my issues. We need to nail down
what's going on there)
(2) OpenSSL has a GPL-incompatible license, and OpenSSL would have to be
used if GnuTLS didn't perform well.
--
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
Re: [Tigervnc-devel] Patch to integrate libssh
I had the same problem in similar testing I have done. OpenSSH does not return an error code for port bind failures. If someone knows of a way to do this without opening ssh in a pipe and parsing the output, I would like to hear it too This was my main reason in suggesting something like libssh. Using it guaranteed getting the detailed error status and being able to act on it by requesting another port etc. On 02/14/2011 05:02 PM, Eric Stadtherr wrote: Do you know of a way to check for the successful bind? One of the behaviors that drove me down the libssh path was that /usr/bin/ssh happily continues running despite failing to bind to the local port. Therefore there is no exit status to interrogate for success/failure. Can you think of a different way to check for successful bind? -- Robert Goley FOSS Implementation Specialist Toll Free: (800) 338-4984 Local: (770) 479-7933 Fax: (770) 479-4076 www.openrda.com America's only Free Open Source fund accounting software company. -- 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
Re: [Tigervnc-devel] Severe performance problem and possible Zlib issue with r4280
IIRC, there is some way to override this path, either at build time or run time or both. I will look into it and see if I can build the DRI library into the distribution. I didn't really care about it because I always just use VirtualGL, but the software renderer really should work for the purposes of completeness. On 2/14/11 3:51 PM, Robert Goley wrote: This is an annoying problem I ran into when I was building and distributing to a couple of machines. Using the build-xorg scripts, it leaves the path hard set to the location of the xorg libraries/modules instead of setting a path and installing them to it with the main tigervnc program. Because these are runtime dynamic load libraries, you do not see an error until you attempt to run the server with those extensions enabled. A quick fix for your testing would be to get the /tmp/tigerbuild.c27921/tigervnc-1.0.90/linux64/xorg.build directory from DRC and extract it to the same path. I would like to find a more permanent way to fix this problem but it should only be an issue on distributions that have a version of xorg too old to build the Xvnc program against it... -- 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
