X2Go Bug report logs - #1109
Print all In new window Long delays (i.e. several minutes) waiting for redraw ONLY in seamless window mode

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.x2go.org (full text, mbox, reply):

From: Thomas Esposito <tmesposito00@gmail.com>

To: submit@bugs.x2go.org

Subject: Print all In new window Long delays (i.e. several minutes) waiting for redraw ONLY in seamless window mode

Date: Thu, 27 Oct 2016 14:37:42 -0400

[Message part 1 (text/plain, inline)]

Package: x2goserver
Version: 4.0.1.19-3
Severity: critical

Server OS: RHEL6.6
Client OS: Windows 7 SP1 64-bit
Server Packages: x2goserver-4.0.1.19-3.el6.x86_64
                           x2goagent-3.5.0.32-3.el6.x86_64
                           nxagent-3.5.0.31-1.el6.x86_64 (not sure if this
is a dependency)
                           nx-libs-3.5.0.31-1.el6.x86_64 (not sure if this
is a dependency)
Client Version: 4.0.5.2

This only occurs when starting a terminal in seamless window mode, and then
launching the "problem" applications from that terminal. I imagine that I'd
observe the same behavior if launching the application directly when the
x2go session is created.

Certain applications experience catastrophically long delays (i.e.
unresponsive for several minutes) during startup and even more so during
reconnect (after a session is suspended). In particular, this happens with
2 Synopsys EDA (Electronic Design Automation) applications that I heavily
rely on, dve and verdi. Obviously, you won't be able to test these because
they require an expensive license, but I can tell you that they are
older-style X11 applications that user X server-side font rendering and
probably don't use a lot of other modern X client-side rendering
techniques.

Luckily, I was able to find a free application that is similarly
unresponsive when starting up in seamless window mode, but that runs fine
in virtual desktop mode: *xcircuit*. This happens to be a free CAD program
for drawing circuit schematics. Obviously, I can't be 100% that this X11
application is failing in the same way as my proprietary EDA tools, but it
is something the x2go developers can look at regardless.

http://opencircuitdesign.com/xcircuit/

In order to diagnose the problem, I ran my applications under xtrace with
the '--relative-timestamps' option in order to see the kind of X11 protocol
traffic that was being generated. In both cases (i.e. my Synopsys EDA
applications and xcircuit), there appear to be MASSIVE amounts of
notifications and events going from the X server to the X client. It seems
like the application's window is made up of a TON on individual rectangle
primitives. If I filter the log file dumped out by xtrace to just show
timestamps, I see HUGE jumps/discontinuities where there are several
seconds or even minutes of apparent inactivity between consecutive
messages. According to top, x2goagent is NOT consuming an excessive amount
of CPU during these period of unresponsiveness.

I don't know much about the details of the X11 protocol, but it almost
seems as if there is some kind of message buffer overrunning somewhere
causing things to get out of sync, only recovering after some kind of
watchdog or timeout mechanism kicks in. If my theory is correct and this
happens repeatedly, it can add up to MINUTES of unresponsiveness. However,
I'm not sure why this would happen only in seamless window mode. Certainly,
one difference between seamless window mode and virtual desktop mode is
that when reconnecting after a suspend, seamless windows are probably going
to see a lot more events from the server (e.g. expose events, window
manipulation notifications, etc.) because of interactions with the locally
running windows which may be in a totally different state compared to when
the x2go session was suspended. In contrast, when running in a virtual
desktop, the applications are contained with a "box" that isolates it from
the state of the local windows on the x2go client side.

It is important to note that, for all of the applications that exhibit this
behavior, once the application has started up (or after suffering long
delays during an x2go reconnect), the application is perfectly functional
and responsive.

[Message part 2 (text/html, inline)]

Message #10 received at 1109@bugs.x2go.org (full text, mbox, reply):

From: Ulrich Sibiller <ulrich.sibiller@gmail.com>

To: Thomas Esposito <tmesposito00@gmail.com>, 1109@bugs.x2go.org

Subject: Re: [X2Go-Dev] Bug#1109: Print all In new window Long delays (i.e. several minutes) waiting for redraw ONLY in seamless window mode

Date: Wed, 16 Nov 2016 22:42:35 +0100

On Thu, Oct 27, 2016 at 8:37 PM, Thomas Esposito <tmesposito00@gmail.com> wrote:
> Package: x2goserver
> Version: 4.0.1.19-3
> Severity: critical
>
> Server OS: RHEL6.6
> Client OS: Windows 7 SP1 64-bit
> Server Packages: x2goserver-4.0.1.19-3.el6.x86_64
>                            x2goagent-3.5.0.32-3.el6.x86_64
>                            nxagent-3.5.0.31-1.el6.x86_64 (not sure if this
> is a dependency)
>                            nx-libs-3.5.0.31-1.el6.x86_64 (not sure if this
> is a dependency)
> Client Version: 4.0.5.2
>
> This only occurs when starting a terminal in seamless window mode, and then
> launching the "problem" applications from that terminal. I imagine that I'd
> observe the same behavior if launching the application directly when the
> x2go session is created.
>
> Certain applications experience catastrophically long delays (i.e.
> unresponsive for several minutes) during startup and even more so during
> reconnect (after a session is suspended). In particular, this happens with 2
> Synopsys EDA (Electronic Design Automation) applications that I heavily rely
> on, dve and verdi. Obviously, you won't be able to test these because they
> require an expensive license, but I can tell you that they are older-style
> X11 applications that user X server-side font rendering and probably don't
> use a lot of other modern X client-side rendering techniques.
>
> Luckily, I was able to find a free application that is similarly
> unresponsive when starting up in seamless window mode, but that runs fine in
> virtual desktop mode: xcircuit. This happens to be a free CAD program for
> drawing circuit schematics. Obviously, I can't be 100% that this X11
> application is failing in the same way as my proprietary EDA tools, but it
> is something the x2go developers can look at regardless.
>
> http://opencircuitdesign.com/xcircuit/
>
> In order to diagnose the problem, I ran my applications under xtrace with
> the '--relative-timestamps' option in order to see the kind of X11 protocol
> traffic that was being generated. In both cases (i.e. my Synopsys EDA
> applications and xcircuit), there appear to be MASSIVE amounts of
> notifications and events going from the X server to the X client. It seems
> like the application's window is made up of a TON on individual rectangle
> primitives. If I filter the log file dumped out by xtrace to just show
> timestamps, I see HUGE jumps/discontinuities where there are several seconds
> or even minutes of apparent inactivity between consecutive messages.
> According to top, x2goagent is NOT consuming an excessive amount of CPU
> during these period of unresponsiveness.
>
> I don't know much about the details of the X11 protocol, but it almost seems
> as if there is some kind of message buffer overrunning somewhere causing
> things to get out of sync, only recovering after some kind of watchdog or
> timeout mechanism kicks in. If my theory is correct and this happens
> repeatedly, it can add up to MINUTES of unresponsiveness. However, I'm not
> sure why this would happen only in seamless window mode. Certainly, one
> difference between seamless window mode and virtual desktop mode is that
> when reconnecting after a suspend, seamless windows are probably going to
> see a lot more events from the server (e.g. expose events, window
> manipulation notifications, etc.) because of interactions with the locally
> running windows which may be in a totally different state compared to when
> the x2go session was suspended. In contrast, when running in a virtual
> desktop, the applications are contained with a "box" that isolates it from
> the state of the local windows on the x2go client side.
>
> It is important to note that, for all of the applications that exhibit this
> behavior, once the application has started up (or after suffering long
> delays during an x2go reconnect), the application is perfectly functional
> and responsive.

This looks like a problem of nx. Can you please try this:
1. run /usr/bin/nxagent -R -ac :5   (you'll see nothing)
2. launch the problematic application:
export DISPLAY=:5
/usr/bin/problematic-app
3. kill -HUP <pid of nxagent> (suspend session)
4. wait some seconds
5. kill -HUP <pid of nxagent> (resume session)

Does this also show the delays? (it doesn't for me with xcircuit, but
I seem to have
some font trouble here. I get lots of 'Error:  font encoding file
missing for font "Helvetica"' messages).


Uli

Message #15 received at 1109@bugs.x2go.org (full text, mbox, reply):

From: Thomas Esposito <tmesposito00@gmail.com>

To: uli42@gmx.de

Cc: 1109@bugs.x2go.org

Subject: Re: [X2Go-Dev] Bug#1109: Print all In new window Long delays (i.e. several minutes) waiting for redraw ONLY in seamless window mode

Date: Thu, 17 Nov 2016 11:18:21 -0500

[Message part 1 (text/plain, inline)]

Where should I be running this from? I tried this from within my existing
x2go session, but I get the following error:

_XSERVTransSocketINETCreateListener: ...SocketCreateListener() failed
_XSERVTransMakeAllCOTSServerListeners: server already running
Error: Aborting session with 'Cannot establish any listening sockets - Make
sure an X server isn't already running'.

Then I tried it from within a VNC session. I was able to run the experiment
you described, but I did not experience delays either with xcircuit or with
my problematic app.

My server is entirely headless BTW. In fact, its a RHEL 6.6 virtual machine
running on my company's VDI infrastructure.

Is there any value to giving you an xtrace dump with relative timestamps?
When I do that, and then sort the log in order of increasing timestamp
values (reported in seconds), I see BIG discontinuities where there can be
DOZENS of seconds between consecutive timestamps.

I'm still betting that the problem has to do with the volume of X protocol
messages. However, I'm not sure why this would be different in rootless vs.
virtual desktop mode (I don't see the problem in virtual desktop mode).

Are you able to reproduce the delays that I'm seeing when running xcircuit
directly within a rootless x2go session (i.e. NOT with your nxagent
experiment). The whole point of using xciruit was because I wanted to find
a FREE application that exhibits the problematic behavior, so that the
developers could more easily reproduce the behavior.

On Wed, Nov 16, 2016 at 4:42 PM, Ulrich Sibiller <ulrich.sibiller@gmail.com>
wrote:

> On Thu, Oct 27, 2016 at 8:37 PM, Thomas Esposito <tmesposito00@gmail.com>
> wrote:
> > Package: x2goserver
> > Version: 4.0.1.19-3
> > Severity: critical
> >
> > Server OS: RHEL6.6
> > Client OS: Windows 7 SP1 64-bit
> > Server Packages: x2goserver-4.0.1.19-3.el6.x86_64
> >                            x2goagent-3.5.0.32-3.el6.x86_64
> >                            nxagent-3.5.0.31-1.el6.x86_64 (not sure if
> this
> > is a dependency)
> >                            nx-libs-3.5.0.31-1.el6.x86_64 (not sure if
> this
> > is a dependency)
> > Client Version: 4.0.5.2
> >
> > This only occurs when starting a terminal in seamless window mode, and
> then
> > launching the "problem" applications from that terminal. I imagine that
> I'd
> > observe the same behavior if launching the application directly when the
> > x2go session is created.
> >
> > Certain applications experience catastrophically long delays (i.e.
> > unresponsive for several minutes) during startup and even more so during
> > reconnect (after a session is suspended). In particular, this happens
> with 2
> > Synopsys EDA (Electronic Design Automation) applications that I heavily
> rely
> > on, dve and verdi. Obviously, you won't be able to test these because
> they
> > require an expensive license, but I can tell you that they are
> older-style
> > X11 applications that user X server-side font rendering and probably
> don't
> > use a lot of other modern X client-side rendering techniques.
> >
> > Luckily, I was able to find a free application that is similarly
> > unresponsive when starting up in seamless window mode, but that runs
> fine in
> > virtual desktop mode: xcircuit. This happens to be a free CAD program for
> > drawing circuit schematics. Obviously, I can't be 100% that this X11
> > application is failing in the same way as my proprietary EDA tools, but
> it
> > is something the x2go developers can look at regardless.
> >
> > http://opencircuitdesign.com/xcircuit/
> >
> > In order to diagnose the problem, I ran my applications under xtrace with
> > the '--relative-timestamps' option in order to see the kind of X11
> protocol
> > traffic that was being generated. In both cases (i.e. my Synopsys EDA
> > applications and xcircuit), there appear to be MASSIVE amounts of
> > notifications and events going from the X server to the X client. It
> seems
> > like the application's window is made up of a TON on individual rectangle
> > primitives. If I filter the log file dumped out by xtrace to just show
> > timestamps, I see HUGE jumps/discontinuities where there are several
> seconds
> > or even minutes of apparent inactivity between consecutive messages.
> > According to top, x2goagent is NOT consuming an excessive amount of CPU
> > during these period of unresponsiveness.
> >
> > I don't know much about the details of the X11 protocol, but it almost
> seems
> > as if there is some kind of message buffer overrunning somewhere causing
> > things to get out of sync, only recovering after some kind of watchdog or
> > timeout mechanism kicks in. If my theory is correct and this happens
> > repeatedly, it can add up to MINUTES of unresponsiveness. However, I'm
> not
> > sure why this would happen only in seamless window mode. Certainly, one
> > difference between seamless window mode and virtual desktop mode is that
> > when reconnecting after a suspend, seamless windows are probably going to
> > see a lot more events from the server (e.g. expose events, window
> > manipulation notifications, etc.) because of interactions with the
> locally
> > running windows which may be in a totally different state compared to
> when
> > the x2go session was suspended. In contrast, when running in a virtual
> > desktop, the applications are contained with a "box" that isolates it
> from
> > the state of the local windows on the x2go client side.
> >
> > It is important to note that, for all of the applications that exhibit
> this
> > behavior, once the application has started up (or after suffering long
> > delays during an x2go reconnect), the application is perfectly functional
> > and responsive.
>
> This looks like a problem of nx. Can you please try this:
> 1. run /usr/bin/nxagent -R -ac :5   (you'll see nothing)
> 2. launch the problematic application:
> export DISPLAY=:5
> /usr/bin/problematic-app
> 3. kill -HUP <pid of nxagent> (suspend session)
> 4. wait some seconds
> 5. kill -HUP <pid of nxagent> (resume session)
>
> Does this also show the delays? (it doesn't for me with xcircuit, but
> I seem to have
> some font trouble here. I get lots of 'Error:  font encoding file
> missing for font "Helvetica"' messages).
>
>
> Uli
>

[Message part 2 (text/html, inline)]

Message #20 received at 1109@bugs.x2go.org (full text, mbox, reply):

From: Aki Ketolainen <akik@mykolab.com>

To: Thomas Esposito <tmesposito00@gmail.com>, 1109@bugs.x2go.org

Subject: Re: [X2Go-Dev] Bug#1109: Print all In new window Long delays (i.e. several minutes) waiting for redraw ONLY in seamless window mode

Date: Fri, 18 Nov 2016 11:38:55 +0200

[Message part 1 (text/plain, inline)]

On 2016-10-27 21:37, Thomas Esposito wrote:

 > Package: x2goserver
 > Version: 4.0.1.19-3
 > Severity: critical
> 
>  Server OS: RHEL6.6
>  Client OS: Windows 7 SP1 64-bit
>  Server Packages: x2goserver-4.0.1.19-3.el6.x86_64
>                             x2goagent-3.5.0.32-3.el6.x86_64
>                             nxagent-3.5.0.31-1.el6.x86_64 (not sure if this is a dependency)
>                              nx-libs-3.5.0.31-1.el6.x86_64 (not sure if this is a dependency)
> Client Version: 4.0.5.2
>
> <cut>
>
> Luckily, I was able to find a free application that is similarly unresponsive when starting up in seamless window mode, but that runs fine in virtual desktop mode: xcircuit. This happens to be a free CAD program for drawing circuit schematics. Obviously, I can't be 100% that this X11 application is failing in the same way as my proprietary EDA tools, but it is something the x2go developers can look at regardless.
>
> http://opencircuitdesign.com/xcircuit/
>
>  <cut> 

Hi, 

I'm experiencing the same effect than you, but the software applications
and operating systems are a bit different.
In my case the slow window redraws happen if:

The client operating system is Ubuntu Linux and the local desktop
environment is either Unity,  XFCE or Mate.
If I'm running Ubuntu Linux on the client machine and the local desktop
environment is either KDE or LXDE, I don't experience the slow window
updates.
I'm running the X2Go server on Azure and it's running CentOS 6.8. The
desktop environment on the server is XFCE.

As you also noticed, the slow window updates only happen with the single
application mode/seamless window mode. 

I haven't tested much with Windows on the client side but the same slow
window updates that you can see just by moving terminal windows on top
of each other is not there
(when you first open one terminal with single application mode and then
open another terminal from the first).

I installed xcircuit on the X2Go server and it starts up and works quite
ok, although I don't have any design file to test with.
We are working on the same EDA field so I'm interested in finding a
solution to this problem.

Bug reports talking about the slow window updates:
http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=1010
http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=1081

Best regards, 

Aki 

  

[Message part 2 (text/html, inline)]

Message #25 received at 1109@bugs.x2go.org (full text, mbox, reply):

From: Thomas Esposito <tmesposito00@gmail.com>

To: akik@iki.fi

Cc: 1109@bugs.x2go.org

Subject: Re: [X2Go-Dev] Bug#1109: Print all In new window Long delays (i.e. several minutes) waiting for redraw ONLY in seamless window mode

Date: Fri, 18 Nov 2016 11:21:44 -0500

[Message part 1 (text/plain, inline)]

I don't have a design file to test xcircuit with either. I only used this
because it was the first free application that I stumbled upon (after some
trial and error) that exhibits this behavior.

In my case, after launching xcircuit from a gnome-terminal in rootless
mode, ALL X applications (including the gnome-terminal) running within the
x2go session become COMPLETELY unresponsive (e.g. no window
redraws/updates) for 5 MINUTES to the point where it almost looks like a
total system lockup. However, during this 5 minute freeze of the x2go
session, I have no problems running other programs on the host (e.g. from
an ssh or VNC session). Also, while my x2go session is apparently frozen,
x2go agent is sipping about 0.3% of the CPU. Eventually, after being frozen
for 5 minutes, my x2go session recovers and I can interact with the
xcircuit application with no apparent delays. Redraws are quick (including
when windows are uncovered from beneath other windows) and everything is
speedy and responsive.

This really seems like some kind of catastrophic network issue where data
is getting lost (e.g. buffer overflows?), and the session won't recover
until 1 (or more) timeouts expire. Maybe it doesn't have to do with the
client OS at all and is instead a function of network conditions (which
would be very difficult to reproduce).

I haven't been able to test this with an x2go client running on Linux
because our RHEL repo only has the packages necessary to run the x2go
server, not the client.



On Fri, Nov 18, 2016 at 4:38 AM, Aki Ketolainen <akik@mykolab.com> wrote:

> On 2016-10-27 21:37, Thomas Esposito wrote:
>
>  > Package: x2goserver
>  > Version: 4.0.1.19-3
>  > Severity: critical
> >
> >  Server OS: RHEL6.6
> >  Client OS: Windows 7 SP1 64-bit
> >  Server Packages: x2goserver-4.0.1.19-3.el6.x86_64
> >                             x2goagent-3.5.0.32-3.el6.x86_64
> >                             nxagent-3.5.0.31-1.el6.x86_64 (not sure if
> this is a dependency)
> >                              nx-libs-3.5.0.31-1.el6.x86_64 (not sure if
> this is a dependency)
> > Client Version: 4.0.5.2
> >
> > <cut>
> >
> > Luckily, I was able to find a free application that is similarly
> unresponsive when starting up in seamless window mode, but that runs fine
> in virtual desktop mode: xcircuit. This happens to be a free CAD program
> for drawing circuit schematics. Obviously, I can't be 100% that this X11
> application is failing in the same way as my proprietary EDA tools, but it
> is something the x2go developers can look at regardless.
> >
> > http://opencircuitdesign.com/xcircuit/
> >
> >  <cut>
>
> Hi,
>
> I'm experiencing the same effect than you, but the software applications
> and operating systems are a bit different.
> In my case the slow window redraws happen if:
>
> The client operating system is Ubuntu Linux and the local desktop
> environment is either Unity,  XFCE or Mate.
> If I'm running Ubuntu Linux on the client machine and the local desktop
> environment is either KDE or LXDE, I don't experience the slow window
> updates.
> I'm running the X2Go server on Azure and it's running CentOS 6.8. The
> desktop environment on the server is XFCE.
>
> As you also noticed, the slow window updates only happen with the single
> application mode/seamless window mode.
>
> I haven't tested much with Windows on the client side but the same slow
> window updates that you can see just by moving terminal windows on top of
> each other is not there
> (when you first open one terminal with single application mode and then
> open another terminal from the first).
>
> I installed xcircuit on the X2Go server and it starts up and works quite
> ok, although I don't have any design file to test with.
> We are working on the same EDA field so I'm interested in finding a
> solution to this problem.
>
> Bug reports talking about the slow window updates:
> http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=1010
> http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=1081
>
> Best regards,
>
> Aki
>
>
>

[Message part 2 (text/html, inline)]

Message #30 received at 1109@bugs.x2go.org (full text, mbox, reply):

From: Aki Ketolainen <akik@mykolab.com>

To: tmesposito00@gmail.com, 1109@bugs.x2go.org

Subject: Re: Print all In new window Long delays (i.e. several minutes) waiting for redraw ONLY in seamless window mode

Date: Fri, 31 Mar 2017 10:33:04 +0300

Hi,

I noticed yesterday that disabling "show window contents while moving"
in Mate desktop and XFCE fix this behaviour. I haven't found the setting
to do this in Unity, though. Also KDE, LXDE and Windows on the client 
side
don't show this behaviour.

@sunweaver on #x2go on freenode commented that
"21:55 <@sunweaver> I guess a sustainabe fix is grabbing the window 
content client side and keep
                    that static pixmap until movement is over."

Best regards,

Aki

Send a report that this bug log contains spam.