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