From tmesposito00@gmail.com Thu Oct 27 20:37:52 2016 Received: (at submit) by bugs.x2go.org; 27 Oct 2016 18:37:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on ymir.das-netzwerkteam.de X-Spam-Level: X-Spam-Status: No, score=-1.5 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 Received: from localhost (localhost [127.0.0.1]) by ymir.das-netzwerkteam.de (Postfix) with ESMTP id 024225DABA for ; Thu, 27 Oct 2016 20:37:52 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at ymir.das-netzwerkteam.de Received: from ymir.das-netzwerkteam.de ([127.0.0.1]) by localhost (ymir.das-netzwerkteam.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6o3IhsOqLWHX for ; Thu, 27 Oct 2016 20:37:45 +0200 (CEST) Received: from mail-vk0-f49.google.com (mail-vk0-f49.google.com [209.85.213.49]) by ymir.das-netzwerkteam.de (Postfix) with ESMTPS id A31A95DA91 for ; Thu, 27 Oct 2016 20:37:44 +0200 (CEST) Received: by mail-vk0-f49.google.com with SMTP id d65so7777284vkg.0 for ; Thu, 27 Oct 2016 11:37:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=96Wve24w6jse+RGWfBJtELgV8sAAv497Z74YBtQ1DH8=; b=ZZU/XUfSpFKM/2wr2HuaiXFwTaY5ojjVRhAqHRSnEytlULOb9mzmRtYzIAICN48iuL TGmLORe+aOAZAEiHJK0porC/6uaQbx6HUcJuLAwqeCh1Ki0DCfv2zilRXKL+cRfspfPb CTRuktIvv5QYYi6qXLeH7DbwFESnvI3gp9Uo+cvLriv22/lngXStILNbxYIjvPuCMroo NspD5uyP29Cc+56xEWoe7Me7RJvYms+mhRTslfaKr0ouzOTdNFKhjS0YTtL1sk+ZIQPG okgr/NBdkoPYTXwkune1ohUXyR0IubLFhegrXDeLBmu7GYCeKxNpyitZrwJZH6iMlVOn GqXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=96Wve24w6jse+RGWfBJtELgV8sAAv497Z74YBtQ1DH8=; b=mCIH0Mjv9NXyyb8LqsJNa7+HnGTTB765iZfawSh9cP90oT6/fZ5nbn05BPGjXpUw9h njvJkhtds2b4vIPfKtd6BgxYZZAmJkMfSHpXTA42rs+MZT3hIYvoIA1FpLF8/WMzp29N tHIszvpm50H63RP0Xc0GSMyD7AbJ6gTPYDdjCWw0l/LUiZ9eoTzqwsvru3suWzIAoKRV 3TdkuzPnZPF37gOHOfaTeR1uw52jSFvUDKOeULdEU2N8uUrEIRwxj1Cv/XSFjZvF13ur DpwM6ccqsk22IINWH+AlxkNSXZpA9javF2cBq8dniq8NaiYlzVGFbtBck5lu3hyqW4Do lhfw== X-Gm-Message-State: ABUngveT6XBSGlelGFFg7eE+N9igk48FgtmrOcsbQ5f9QJeI6TiaG9TyXFsMJ3zOVKAfWE0He+L2Hsa1yTkfVg== X-Received: by 10.31.93.198 with SMTP id r189mr3634436vkb.39.1477593463096; Thu, 27 Oct 2016 11:37:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.44.130 with HTTP; Thu, 27 Oct 2016 11:37:42 -0700 (PDT) From: Thomas Esposito Date: Thu, 27 Oct 2016 14:37:42 -0400 Message-ID: Subject: Print all In new window Long delays (i.e. several minutes) waiting for redraw ONLY in seamless window mode To: submit@bugs.x2go.org Content-Type: multipart/alternative; boundary=94eb2c0949cc7d8a83053fdd0900 --94eb2c0949cc7d8a83053fdd0900 Content-Type: text/plain; charset=UTF-8 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. --94eb2c0949cc7d8a83053fdd0900 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Package: x2goserver
<= div style=3D"font-size:12.8px">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
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0x2goagent-3.5.0.32-3= .el6.x86_64
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0nxagent-3.5.0.31-1.el6.x86_64 (not sure if this is a dependency)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0nx-libs-3.5.0.31-1.e= l6.x86_64 (not sure if this is a dependency)
Client Version: 4.0.5.2

This only occurs when starting a termina= l in seamless window mode, and then launching the "problem" appli= cations from that terminal. I imagine that I'd observe the same behavio= r if launching the application directly when the x2go session is created.

Certain applications experience catastrophically long delays (i.e. unres= ponsive for several minutes) during startup and even more so during reconne= ct (after a session is suspended). In particular, this happens with 2 Synop= sys 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&#= 39;t use a lot of other modern X client-side rendering techniques.=C2=A0

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


In order to diagnose the problem, I ran my app= lications under xtrace with the '--relative-timestamps' option in o= rder to see the kind of X11 protocol traffic that was being generated. In b= oth 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 TO= N on individual rectangle primitives. If I filter the log file dumped out b= y xtrace to just show timestamps, I see HUGE jumps/discontinuities where th= ere are several seconds or even minutes of apparent inactivity between cons= ecutive messages. According to top, x2goagent is NOT consuming an excessive= amount of CPU during these period of unresponsiveness.

I don't kno= w much about the details of the X11 protocol, but it almost seems as if the= re is some kind of message buffer overrunning somewhere causing things to g= et out of sync, only recovering after some kind of watchdog or timeout mech= anism 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 betwee= n seamless window mode and virtual desktop mode is that when reconnecting a= fter a suspend, seamless windows are probably going to see a lot more event= s from the server (e.g. expose events, window manipulation notifications, e= tc.) because of interactions with the locally running windows which may be = in a totally different state compared to when the x2go session was suspende= d. In contrast, when running in a virtual desktop, the applications are con= tained with a "box" that isolates it from the state of the local = windows on the x2go client side.

<= /div>
It is important to note that, for all = of the applications that exhibit this behavior, once the application has st= arted up (or after suffering long delays during an x2go reconnect), the app= lication is perfectly functional and responsive.=C2=A0
--94eb2c0949cc7d8a83053fdd0900-- From ulrich.sibiller@gmail.com Wed Nov 16 22:43:04 2016 Received: (at 1109) by bugs.x2go.org; 16 Nov 2016 21:43:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on ymir.das-netzwerkteam.de X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,FREEMAIL_REPLYTO, FREEMAIL_REPLYTO_END_DIGIT autolearn=no version=3.3.2 Received: from localhost (localhost [127.0.0.1]) by ymir.das-netzwerkteam.de (Postfix) with ESMTP id 7499C3CBB6 for <1109@bugs.x2go.org>; Wed, 16 Nov 2016 22:43:04 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at ymir.das-netzwerkteam.de Received: from ymir.das-netzwerkteam.de ([127.0.0.1]) by localhost (ymir.das-netzwerkteam.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpfF7vlEYtul for <1109@bugs.x2go.org>; Wed, 16 Nov 2016 22:42:57 +0100 (CET) Received: from mail-ua0-f177.google.com (mail-ua0-f177.google.com [209.85.217.177]) by ymir.das-netzwerkteam.de (Postfix) with ESMTPS id 742773CBB5 for <1109@bugs.x2go.org>; Wed, 16 Nov 2016 22:42:57 +0100 (CET) Received: by mail-ua0-f177.google.com with SMTP id 12so126220418uas.2 for <1109@bugs.x2go.org>; Wed, 16 Nov 2016 13:42:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to; bh=AHjb3MTlUL+Ty65RgtrPTd54IAX05+ogP1KLvyClsIQ=; b=AsDTlhGtVVyGF7Ro10SK84Kx60Ur+1XVFVl2YkNUCU0pP0spmBCwO+4AmqSKARgd8U hsQCCsdTfwO//JmA/BT7W8UZ3kmHE2ogUjSHAjlYImCLW0mdgvvYDfdCfOrmiv5pWSlj EffPos6evRzLEoLZl9bWPzzWVmtZUuTkXrfNI5T/BH9bGO6CRwFirjN48xSWOZ2Ew/gp hNUcUG4edIuT45mt8yEx5OgVDviX3FTRHs0OvdaP++7zl1q7ON8ueM+rwsBhtyzGRtXn FXwmvYu1VLOKEG0p8iZx2MAV0f1Xux18cOEfTbfGad/R4T8Vu2Mf8Gq34SDYL/qqE0Wg Ts7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to; bh=AHjb3MTlUL+Ty65RgtrPTd54IAX05+ogP1KLvyClsIQ=; b=OSYMuJJ6H7WC/8VHbztfwCGdogaqDYz9O3iiNbjxGMhrfWzA5NfVGFw2Au4gHor0y0 yYWweUeB3aG1ct5nvM1i+kc9CA9H12vvtuFO9KRDwz0AH6Efp2PM4Y594qHQA57Btfq6 WVtUCBSZGfxcLDQlBWeI6O6SPVwDF9YpygvctJPnWr/dETgFxfoNphxyXpD+IpfvIR2h cokOtfaKqRIEX90lJmWxRqVs+nLRxXYuyD4gyjt0op4mM/CgG1bZG3s5kp5a/rGSnY1o r7K0BU5RdIVCCZBs16tU4re6Grv/g8m4BR+NSqbUisn+Jcdn+XrUKyPOJCC2q4amh6x1 g7lA== X-Gm-Message-State: ABUngvc6qsuRO39f9hU8ty4/c1EGo9WOZ+8QjdtU4xp0T5ARy0v47pTAVtitX2N1pYmu051zXoipR8mHsCttLw== X-Received: by 10.176.2.21 with SMTP id 21mr3275103uas.11.1479332576165; Wed, 16 Nov 2016 13:42:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.149.156 with HTTP; Wed, 16 Nov 2016 13:42:35 -0800 (PST) Reply-To: uli42@gmx.de In-Reply-To: References: From: Ulrich Sibiller Date: Wed, 16 Nov 2016 22:42:35 +0100 Message-ID: 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 To: Thomas Esposito , 1109@bugs.x2go.org Content-Type: text/plain; charset=UTF-8 On Thu, Oct 27, 2016 at 8:37 PM, 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 > > 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 (suspend session) 4. wait some seconds 5. kill -HUP (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 From tmesposito00@gmail.com Thu Nov 17 17:18:31 2016 Received: (at 1109) by bugs.x2go.org; 17 Nov 2016 16:18:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on ymir.das-netzwerkteam.de X-Spam-Level: X-Spam-Status: No, score=-2.0 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE autolearn=ham version=3.3.2 Received: from localhost (localhost [127.0.0.1]) by ymir.das-netzwerkteam.de (Postfix) with ESMTP id CBB843CBB6 for <1109@bugs.x2go.org>; Thu, 17 Nov 2016 17:18:30 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at ymir.das-netzwerkteam.de Received: from ymir.das-netzwerkteam.de ([127.0.0.1]) by localhost (ymir.das-netzwerkteam.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ES7pgBPRJu-d for <1109@bugs.x2go.org>; Thu, 17 Nov 2016 17:18:24 +0100 (CET) Received: from mail-it0-f45.google.com (mail-it0-f45.google.com [209.85.214.45]) by ymir.das-netzwerkteam.de (Postfix) with ESMTPS id C2A383CBB5 for <1109@bugs.x2go.org>; Thu, 17 Nov 2016 17:18:23 +0100 (CET) Received: by mail-it0-f45.google.com with SMTP id l8so147180788iti.1 for <1109@bugs.x2go.org>; Thu, 17 Nov 2016 08:18:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Xklfgp2IXupIb+iOon8gjf9BOBICB+Cq2cHDBltZC38=; b=AA+VaNS3HbCWiJrgJ7NABBpp/DwtCv49urId5k8Pqnjt0GwYoYLw8TYBDtrJE/ufdm rQ1pJtEdf+ywnbziODaezd0LL4hkv0atHPJbWUEGDyZjO2lgLVeEPX1iSKNxUaOtvpFe AhVVlovMDQWbQTMg2S5b0T6CnGbPLw1U20o6JM8asRpmqk7ejjEATc1vvd4/Y7fGz0Sq luHkASnG0BmGq7fH/n1sSlNpJ8h3gJqNXI84CTHJBBc/c8Q5sdRwAgMbufXvUkY5Bm8y JDeaEP0qpsSEcpIdQI5J94vqVb63+wTJQw5NW493ilhzHLZys2gJhtDwcHwzS3uSRfwP NN3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Xklfgp2IXupIb+iOon8gjf9BOBICB+Cq2cHDBltZC38=; b=BunN0WwKJTkpQ8esWPN972inqToa8yRY+Zu8/7NGZyig+Q8ezCUxMrgLofTDv89WT2 PickJMNSIzhJIiH/aQX5kBP1rcJCrn84WlKqaC31ZmBOmD5UqtSUHeHpJ6WGgKsJrIRh Yhz5AhEHPuYMjpjm8kmWxj5QSJ4PAdRFSTee79to0eO+5DqSwB24j5uJZLQN68bIuLr1 uECxR+n4MpBMlHsGK2bGZnINKW96ok8jMQe7vAiSLKwKwISdNPyiDSMqwIX0HUNo0J98 aymkXC9EMxJcms4DV5VET/ltKiCD+yINeLyFdyTLTPEm3e5oUPhUn+tuu3lb6LAG1C5R ZyeA== X-Gm-Message-State: ABUngvcITXeJQzc1RYlTXgE3/QhrbnUgFCm6yYn/DGdxmI1IDJVSVXAwtvl3Ruy/BVoiGnr7jrm/ADOQeSzBWA== X-Received: by 10.157.49.20 with SMTP id e20mr1695822otc.121.1479399502260; Thu, 17 Nov 2016 08:18:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.47.5 with HTTP; Thu, 17 Nov 2016 08:18:21 -0800 (PST) In-Reply-To: References: From: Thomas Esposito Date: Thu, 17 Nov 2016 11:18:21 -0500 Message-ID: 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 To: uli42@gmx.de Cc: 1109@bugs.x2go.org Content-Type: multipart/alternative; boundary=001a114154b0d04616054181898c --001a114154b0d04616054181898c Content-Type: text/plain; charset=UTF-8 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 wrote: > On Thu, Oct 27, 2016 at 8:37 PM, 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 > > > > 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 (suspend session) > 4. wait some seconds > 5. kill -HUP (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 > --001a114154b0d04616054181898c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Where should I be running this from? I tried this from wit= hin my existing x2go session, but I get the following error:

=
_XSERVTransSocketINETCreateListener: ...SocketCreateListener() fa= iled
_XSERVTransMakeAllCOTSServerListeners: server already runnin= g
Error: Aborting session with 'Cannot establish any listenin= g 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 eithe= r with xcircuit or with my problematic app.

My ser= ver is entirely headless BTW. In fact, its a RHEL 6.6 virtual machine runni= ng on my company's VDI infrastructure.

Is ther= e any value to giving you an xtrace dump with relative timestamps? When I d= o that, and then sort the log in order of increasing timestamp values (repo= rted in seconds), I see BIG discontinuities where there can be DOZENS of se= conds between consecutive timestamps.

I'm stil= l 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. vir= tual desktop mode (I don't see the problem in virtual desktop mode).

Are you able to reproduce the delays that I'm se= eing when running xcircuit directly within a rootless x2go session (i.e. NO= T with your nxagent experiment). The whole point of using xciruit was becau= se I wanted to find a FREE application that exhibits the problematic behavi= or, so that the developers could more easily reproduce the behavior.
<= /div>

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 <t= mesposito00@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
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 x2goagent-3.5.0.32-3.el6.x86_64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 nxagent-3.5.0.31-1.el6.x86_64 (not sure if this=
> is a dependency)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 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 i= magine that I'd
> observe the same behavior if launching the application directly when t= he
> x2go session is created.
>
> Certain applications experience catastrophically long delays (i.e.
> unresponsive for several minutes) during startup and even more so duri= ng
> reconnect (after a session is suspended). In particular, this happens = with 2
> Synopsys EDA (Electronic Design Automation) applications that I heavil= y rely
> on, dve and verdi. Obviously, you won't be able to test these beca= use they
> require an expensive license, but I can tell you that they are older-s= tyle
> X11 applications that user X server-side font rendering and probably d= on'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 f= ine 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 X= 11
> application is failing in the same way as my proprietary EDA tools, bu= t 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 w= ith
> 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<= br> > applications and xcircuit), there appear to be MASSIVE amounts of
> notifications and events going from the X server to the X client. It s= eems
> like the application's window is made up of a TON on individual re= ctangle
> primitives. If I filter the log file dumped out by xtrace to just show=
> timestamps, I see HUGE jumps/discontinuities where there are several s= econds
> or even minutes of apparent inactivity between consecutive messages. > According to top, x2goagent is NOT consuming an excessive amount of CP= U
> during these period of unresponsiveness.
>
> I don't know much about the details of the X11 protocol, but it al= most seems
> as if there is some kind of message buffer overrunning somewhere causi= ng
> 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&#= 39;m not
> sure why this would happen only in seamless window mode. Certainly, on= e
> difference between seamless window mode and virtual desktop mode is th= at
> 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 loc= ally
> 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 is= olates 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 functio= nal
> and responsive.

This looks like a problem of nx. Can you please try this:
1. run /usr/bin/nxagent -R -ac :5=C2=A0 =C2=A0(you'll see nothing)
2. launch the problematic application:
export DISPLAY=3D: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:=C2=A0 font encoding file<= br> missing for font "Helvetica"' messages).


Uli

--001a114154b0d04616054181898c-- From akik@mykolab.com Fri Nov 18 10:46:06 2016 Received: (at 1109) by bugs.x2go.org; 18 Nov 2016 09:46:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on ymir.das-netzwerkteam.de X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,FREEMAIL_FROM, HTML_MESSAGE autolearn=ham version=3.3.2 Received: from localhost (localhost [127.0.0.1]) by ymir.das-netzwerkteam.de (Postfix) with ESMTP id EB03A3CBB6 for <1109@bugs.x2go.org>; Fri, 18 Nov 2016 10:46:05 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at ymir.das-netzwerkteam.de Received: from ymir.das-netzwerkteam.de ([127.0.0.1]) by localhost (ymir.das-netzwerkteam.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6gFNXrurvf9 for <1109@bugs.x2go.org>; Fri, 18 Nov 2016 10:45:58 +0100 (CET) X-Greylist: delayed 420 seconds by postgrey-1.34 at ymir.das-netzwerkteam.de; Fri, 18 Nov 2016 10:45:58 CET Received: from mx-out03.mykolab.com (mx.kolabnow.com [95.128.36.1]) by ymir.das-netzwerkteam.de (Postfix) with ESMTPS id A310B3CBB5 for <1109@bugs.x2go.org>; Fri, 18 Nov 2016 10:45:58 +0100 (CET) X-Virus-Scanned: amavisd-new at kolabnow.com Received: from mx05.mykolab.com (mx05.mykolab.com [10.20.7.161]) by mx-out03.mykolab.com (Postfix) with ESMTPS id 8592721EB7; Fri, 18 Nov 2016 10:38:56 +0100 (CET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_67d3b55859e7397e4b2bd536235c15df" Date: Fri, 18 Nov 2016 11:38:55 +0200 From: Aki Ketolainen To: Thomas Esposito , 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 Reply-To: akik@iki.fi Mail-Reply-To: akik@iki.fi In-Reply-To: References: Message-ID: <909cd94234462d1675f2c3d8ab4f2f18@mykolab.com> X-Sender: akik@mykolab.com --=_67d3b55859e7397e4b2bd536235c15df Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII 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 > > > > 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/ > > 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 --=_67d3b55859e7397e4b2bd536235c15df Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

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

 > Packag= e: x2goserver
 > Version: 4.0.1.19-3
 > Severity:= critical
>
>  Server OS: RHEL6.6
>  Cli= ent OS: Windows 7 SP1 64-bit
>  Server Packages: x2goserver-4= =2E0.1.19-3.el6.x86_64
>       &= nbsp;           &nbs= p;         x2goagent-3.5.0.32-3.el6= =2Ex86_64
>         &n= bsp;            = ;       nxagent-3.5.0.31-1.el6.x86_64 (not su= re if this is a dependency)
>      &n= bsp;            = ;           nx-libs-3.5= =2E0.31-1.el6.x86_64 (not sure if this is a dependency)
> Client Ve= rsion: 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 s= chematics. 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 d= evelopers can look at regardless.
>
> http://opencircuitdes= ign.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 en= vironment is either KDE or LXDE, I don't experience the slow window updates= =2E
I'm running the X2Go server on Azure and it's running CentOS 6.8= =2E The desktop environment on the server is XFCE.

As you also n= oticed, the slow window updates only happen with the single application mod= e/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 e= ach other is not there
(when you first open one terminal with single a= pplication 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 o= n the same EDA field so I'm interested in finding a solution to this proble= m.

Bug reports talking about the slow window updates:
http://bugs.x2= go.org/cgi-bin/bugreport.cgi?bug=3D1010
http://bugs.x2go.org/cgi-bin/bugrep= ort.cgi?bug=3D1081


Best regards,

Aki

 

--=_67d3b55859e7397e4b2bd536235c15df-- From tmesposito00@gmail.com Fri Nov 18 17:21:54 2016 Received: (at 1109) by bugs.x2go.org; 18 Nov 2016 16:21:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on ymir.das-netzwerkteam.de X-Spam-Level: X-Spam-Status: No, score=-1.5 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 Received: from localhost (localhost [127.0.0.1]) by ymir.das-netzwerkteam.de (Postfix) with ESMTP id D38CC3CBB6 for <1109@bugs.x2go.org>; Fri, 18 Nov 2016 17:21:53 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at ymir.das-netzwerkteam.de Received: from ymir.das-netzwerkteam.de ([127.0.0.1]) by localhost (ymir.das-netzwerkteam.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wiR55dgOTLYL for <1109@bugs.x2go.org>; Fri, 18 Nov 2016 17:21:47 +0100 (CET) Received: from mail-oi0-f66.google.com (mail-oi0-f66.google.com [209.85.218.66]) by ymir.das-netzwerkteam.de (Postfix) with ESMTPS id B75713CBB5 for <1109@bugs.x2go.org>; Fri, 18 Nov 2016 17:21:46 +0100 (CET) Received: by mail-oi0-f66.google.com with SMTP id z62so11616646oiz.1 for <1109@bugs.x2go.org>; Fri, 18 Nov 2016 08:21:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+caUvrFhCnOrJpirabPnWTN3KuoOBe8PQxp67Ry8lCY=; b=Re8rDcM8RURQArDP5x5Fk5UYnMUs39AFI/U+OeTIx5AYMzLMYUGxCrl9CokysixYpY gQALO1PCT6dBk45glsqVPa/T+Cid7z2PXzX5wUSsDi40Hw2qjBShIequySTDDhRuZdXk GI/A8shKxmLAqe0nti4IzvAXhAAPY1x9kpVi47XnGsxkyTUEvJGTPOAgfT/1hupZ3qzK qhhWasFwaM+9L0qad+UzYVuuwI51c0/7UIrnZzblC9/SNxmxlkSyQeL9TLKSnQI9d4RJ M1Uw+BWOTQG4Po6TCLhNkI8R3k6dC438PF/RFMwFNBHIyDq6sYmzC8oWQLjY/DbpNheU SQWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+caUvrFhCnOrJpirabPnWTN3KuoOBe8PQxp67Ry8lCY=; b=GTqLPB8dnxqXHySRs45pG9t9ne6Rvu2AywhU35cHYlupANn3sce74iDPmKfNwI2GhN yAD/lPS/q0HVYW/7BFxhIPoGQyj+47LputswE1ZYpq8wq2ejXjHFu6pWOQKUfkYMgbel gI3MQfEddD3sPPWLzFMBu040R16ReBcAaWF4W1wwTHvu8VXabkAaRJNxO0zjCVIvGUC1 bgP3Q4GexM8mUXzvZ3EoVoW1vhq3YRcx80vo8GtRm8Z4csCpE2uOl/NEJbN9mjvyM8kg paRdWAwdwZzaL9OZ/1ogaPMU8TcpwXDINpuYm+s3HXK+aRhPP82gOyBdsfgPYW95NRd1 XyUg== X-Gm-Message-State: AKaTC02SMTwH0joxURONRI7iAlCm7cGSmv3L5kUggIYCzmqcs2Qvcr9ba/oS8A525hGxduQuhsDvS0RRkbYimQ== X-Received: by 10.202.189.86 with SMTP id n83mr324055oif.49.1479486105430; Fri, 18 Nov 2016 08:21:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.35.29 with HTTP; Fri, 18 Nov 2016 08:21:44 -0800 (PST) In-Reply-To: <909cd94234462d1675f2c3d8ab4f2f18@mykolab.com> References: <909cd94234462d1675f2c3d8ab4f2f18@mykolab.com> From: Thomas Esposito Date: Fri, 18 Nov 2016 11:21:44 -0500 Message-ID: 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 To: akik@iki.fi Cc: 1109@bugs.x2go.org Content-Type: multipart/alternative; boundary=001a113d6ea8c3afaa054195b345 --001a113d6ea8c3afaa054195b345 Content-Type: text/plain; charset=UTF-8 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 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 > > > > > > > > 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/ > > > > > > 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 > > > --001a113d6ea8c3afaa054195b345 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't have a design file to test xcircuit with eithe= r. I only used this because it was the first free application that I stumbl= ed upon (after some trial and error) that exhibits this behavior.

<= /div>
In my case, after launching xcircuit from a gnome-terminal in roo= tless mode, ALL X applications (including the gnome-terminal) running withi= n the x2go session become COMPLETELY unresponsive (e.g. no window redraws/u= pdates) for 5 MINUTES to the point where it almost looks like a total syste= m 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 ses= sion). Also, while my x2go session is apparently frozen, x2go agent is sipp= ing 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 wit= h no apparent delays. Redraws are quick (including when windows are uncover= ed from beneath other windows) and everything is speedy and responsive.

This really seems like some kind of catastrophic netw= ork issue where data is getting lost (e.g. buffer overflows?), and the sess= ion 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 networ= k conditions (which would be very difficult to reproduce).

I haven't been able to test this with an x2go client running o= n Linux because our RHEL repo only has the packages necessary to run the x2= go 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:

=C2= =A0> Package: x2goserver
=C2=A0> Version: 4.0.1.19-3
=C2=A0>= Severity: critical
>
>=C2=A0 Server OS: RHEL6.6
>=C2=A0= Client OS: Windows 7 SP1 64-bit
>=C2=A0 Server Packages: x2goserver-= 4.0.1.19-3.el6.x86_64
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x2goagent-3.5.0.32-3= .el6.x86_64
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 nxagent-3.5.0.31-1.el6.x86_64 (n= ot sure if this is a dependency)
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 nx-libs-= 3.5.0.31-1.el6.x86_64 (not sure if this is a dependency)
> Client Ver= sion: 4.0.5.2
>
> <cut>
>> Luckily, I was able to find a free application that is similarly unr= esponsive when starting up in seamless window mode, but that runs fine in v= irtual desktop mode: xcircuit. This happens to be a free CAD program for dr= awing circuit schematics. Obviously, I can't be 100% that this X11 appl= ication is failing in the same way as my proprietary EDA tools, but it is s= omething the x2go developers can look at regardless.
>
> http://openc= ircuitdesign.com/xcircuit/
>
>=C2=A0 <cut>= ;

Hi,

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

The client operating system is Ubuntu Linux an= d the local desktop environment is either Unity,=C2=A0 XFCE or Mate.
If = I'm running Ubuntu Linux on the client machine and the local desktop en= vironment is either KDE or LXDE, I don't experience the slow window upd= ates.
I'm running the X2Go server on Azure and it's running Cent= OS 6.8. The desktop environment on the server is XFCE.

As you also n= oticed, the slow window updates only happen with the single application mod= e/seamless window mode.

I haven't tested much with Windows on the client side but the same s= low 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 o= n the same EDA field so I'm interested in finding a solution to this pr= oblem.

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

Bes= t regards,

Aki

=C2=A0


--001a113d6ea8c3afaa054195b345-- From akik@mykolab.com Fri Mar 31 09:39:56 2017 Received: (at 1109) by bugs.x2go.org; 31 Mar 2017 07:39:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on ymir.das-netzwerkteam.de X-Spam-Level: X-Spam-Status: No, score=0.8 required=3.0 tests=BAYES_50,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.1 Received: from localhost (localhost [127.0.0.1]) by ymir.das-netzwerkteam.de (Postfix) with ESMTP id 059065DAD1 for <1109@bugs.x2go.org>; Fri, 31 Mar 2017 09:39:56 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at ymir.das-netzwerkteam.de Received: from ymir.das-netzwerkteam.de ([127.0.0.1]) by localhost (ymir.das-netzwerkteam.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vtrP6b519sU for <1109@bugs.x2go.org>; Fri, 31 Mar 2017 09:39:49 +0200 (CEST) X-Greylist: delayed 402 seconds by postgrey-1.35 at ymir.das-netzwerkteam.de; Fri, 31 Mar 2017 09:39:49 CEST Received: from mx-out02.mykolab.com (mx.kolabnow.com [95.128.36.1]) by ymir.das-netzwerkteam.de (Postfix) with ESMTPS id 12D2F5DA4D for <1109@bugs.x2go.org>; Fri, 31 Mar 2017 09:39:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at kolabnow.com Received: from mx03.mykolab.com (mx03.mykolab.com [10.20.7.101]) by mx-out02.mykolab.com (Postfix) with ESMTPS id 9E40461710; Fri, 31 Mar 2017 09:33:05 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 31 Mar 2017 10:33:04 +0300 From: Aki Ketolainen 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 Reply-To: akik@iki.fi Mail-Reply-To: akik@iki.fi Message-ID: <23a2387342f310e376c1c9090db6f2de@mykolab.com> X-Sender: akik@mykolab.com 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