From hrvoje.habjanic@zg.ht.hr Tue Mar 10 16:13:03 2015 Received: (at submit) by bugs.x2go.org; 10 Mar 2015 15:13: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.8 required=5.0 tests=BAYES_50 autolearn=ham version=3.3.2 X-Greylist: delayed 419 seconds by postgrey-1.34 at ymir.das-netzwerkteam.de; Tue, 10 Mar 2015 16:13:03 CET Received: from ls405.t-com.hr (ls405.t-com.hr [195.29.150.135]) by ymir.das-netzwerkteam.de (Postfix) with ESMTP id 783AF5E15C for ; Tue, 10 Mar 2015 16:13:03 +0100 (CET) Received: from ls266.t-com.hr (ls266.t-com.hr [195.29.150.94]) by ls405.t-com.hr (Postfix) with ESMTP id 569F0698A63 for ; Tue, 10 Mar 2015 16:06:04 +0100 (CET) Received: from ls266.t-com.hr (localhost.localdomain [127.0.0.1]) by ls266.t-com.hr (Qmlai) with ESMTP id 53BD9C58240 for ; Tue, 10 Mar 2015 16:06:04 +0100 (CET) X-Envelope-Sender: hrvoje.habjanic@zg.ht.hr Received: from habi.t-com.hr (habi.t-com.hr [195.29.148.138]) by ls266.t-com.hr (Qmali) with ESMTP id 131DA19D8146 for ; Tue, 10 Mar 2015 16:06:04 +0100 (CET) Received: from [192.168.11.10] (unknown [192.168.11.10]) by habi.t-com.hr (Postfix) with ESMTP id D4E4260F13 for ; Tue, 10 Mar 2015 16:06:03 +0100 (CET) Message-ID: <54FF085B.1040608@zg.ht.hr> Date: Tue, 10 Mar 2015 16:06:03 +0100 From: =?UTF-8?B?SHJ2b2plIEhhYmphbmnEhw==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: submit@bugs.x2go.org Subject: Performance drop using large virtual screen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1018-21390.000 X-TM-AS-Result: No--10.712-10.0-31-1 X-imss-scan-details: No--10.712-10.0-31-1 X-TM-AS-User-Approved-Sender: No Package: x2goserver Version: 4.0.1.19-0~1062~ubuntu14.04.1 Hi. I noticed that using large screens (bigger than 800x600) causes x2go to start slowing down. Especially problematic are full-screen switches, for example when you switch from one virtual screen to another, inside of x2go virtual screen. This slow down is experienced as sudden session freeze, depending on screen size, it can stall for up to few seconds. After some time this becomes really annoying ... This is not influenced by switching to different encoding or line speed in GUI. Eventually i did track down to cache sizes. In /usr/bin/x2gostartagent file there is fixed cache size: "cache=8M,disk=32M". Increasing this cache size completely removes this freeze, and also significantly reduces session bandwidth! For example, with session 1680x1050, using 16bit RLE, changing cache to "64M" bandwidth drops from 3-4Mbit/s down to ~200kbit/s! I also noticed better responsiveness when using "disk=0". So, it seems that default settings (cache=8M,disk=32M) are maybe too small for todays use with lager virtual screens, and this should be increased. I would suggest using at least "cache=64M" as default. Also, it would be nice to add a possibility to change those values in a nice way, since directly editing the script is more like a hack. Also, when script is updated, changes are lost. Regards, H.