[16:42] <ksteffensen> Hi all.  I'm supporting a school in Tanzania from the US.  (I lived there in 2006-2007 and set up Edubuntu then.  I've been working with their Principal to keep it going since then.)  We just set up a new server with an i7 and 16 GB of RAM.  It's doing great with one exception.  Some software that ran fine on an older slower server with less ram under 10.04 is now bogging the system down to...
[16:42] <ksteffensen> ...be unusable under 12.04.  Specifically KTouch, KTurtle, and Scribus.  Has anyone else seen this?  Top shows that the CPU is only at 15% and only 9 GB of RAM is being used when the multiple users are using KTurtle and bogging down the system.  Other programs like Libre Office work fine with multiple users.
[16:43] <ksteffensen> Thanks in advance for any insight.
[16:45] <highvoltage> hey ksteffensen
[16:46] <ksteffensen> Hi, highvoltage
[16:47] <highvoltage> hmm, I can't think of anything that's detoriated performance-wise with KDE apps, and ktouch and kturtle aren't /that/ graphics intensive.
[16:47] <highvoltage> ksteffensen: could it perhaps be that they had LDM_DIRECTX enabled in the old setup and not in the new one?
[16:48] <highvoltage> (that makes quite a performance difference in LTSP setups)
[16:48] <ksteffensen> I'll check.  Could be.
[16:48] <ksteffensen> thanks.
[16:49] <highvoltage> I sometimes run "ethstatus" as well (not part of the default installation but quick to install) just to see what the network is doing when the system is slow
[16:49] <ksteffensen> the school has found alternatives to ktouch and kturtle that are working, but it would be good to figure this out.
[16:49] <ksteffensen> thanks.  I'll install that, too.
[16:50] <highvoltage> also do an 'ifconfig' and check that the 'lo' interface is up and has an ip address of 127.0.0.1
[16:50] <highvoltage> it's very rare but I've seen some people mess up their networking somehow so that it's not configured anymore
[16:50] <highvoltage> and that has a big impact on KDE applications specifically
[16:51] <ksteffensen> localhost is 127.0.0.1 on the server.
[16:51] <highvoltage> ok good
[16:59] <ksteffensen> highvoltage: the old server is powered off.  I've asked the principal to walk over to the school and power it on.  In the mean time, it sounds like I should add LDM_DIRECTX=True to lts.conf in any event, right?
[17:02] <highvoltage> ksteffensen: it depends, that comes at a security cost, since UI input/output goes over the network unencrypted. so if the users have to type any sensitive passwords, for example, then it's a good idea not to enable it
[17:02] <highvoltage> ksteffensen: quite often that's not a problem in classrooms
[17:03] <ksteffensen> thanks.  it's all kids without sudo on a non-routable subnet, so I don't think it will be a problem.  But I can see how you wouldn't want to use it in an internet cafe or the like.
[17:03] <highvoltage> ksteffensen: another thing to check, perhaps a few apps were local apps in the previous setup. I usually set up gcompris as a local app since it tends to take up a lot of server resources very quickly and bog things down
[17:04] <highvoltage> (we actually kind of need a "I have LTSP working, what do I do now" kind of guide)
[17:05] <ksteffensen> i'm 95% sure that all were running on the server in the old setup, but I'll double check.  I hadn't thought about moving any apps to be local.  does it still use LDM for login, etc, but then just use local resources for running that specific app?
[17:07] <lmk> ksteffensen: check out the mailing list, kde performance was discussed just recently
[17:07] <ksteffensen> thanks.  checking  it now.
[17:07] <lmk> Qt changed some backend setting causing increased X network traffic
[17:08] <ksteffensen> (I had actually just subscribed to it and was going to send a note to it if no one on here had any ideas.  Thanks for the pointer.  I hadn't checked the archives yet.)
[17:09] <lmk> http://sourceforge.net/mailarchive/message.php?msg_id=30046932
[17:11] <ksteffensen> lmk: outstanding!  Thanks.  I'll get them to try it asap.
[17:11] <lmk> np :)
[17:11] <alkisg> Wow... "FWIW, Qt 5 will not support "native" at all. :-("
[17:12]  * alkisg thinks LXDE will probably be the only working DE with LTSP in the near future... :(
[17:12] <stgraber> yeah and as long as you don't run any app on it
[17:13] <alkisg> Hehe, possibly :D
[17:13] <stgraber> because everything will blow up as soon as you try to run any of the kdeedu games, firefox, ...
[17:13] <alkisg> Btw, I've seen some huge regression with GTK xorg cpu usage recently
[17:13] <alkisg> I.e. thin clients with enough RAM but slow CPU are unusable in 12.04 while they were working fine in 10.04
[17:14] <alkisg> Xterm scrolls really fast; dillo too; other apps really suck, 1 fps
[17:14]  * alkisg wants to check for any gtk options similar to that "native" one for Qt... maybe something with caching or backingstores etc
[17:16] <alkisg> I'm really thinking about using Win 98 + rdp to XP pro machines to revive some of those old computers :-/
[17:26] <ksteffensen> alkisg: I just found the note about "FWIW, Qt 5 will not support "native" at all. :-(" too.  That really stinks.  A lot of the good programs for education are in the KDE world.  (Or at least the ones that we're used to using...)
[17:27] <alkisg> ksteffensen: I've also noticed that KDE reads about 600mb from the disk on logins... very unfriendly for multi-user setups
[17:28] <alkisg> Fortunately we only use a single KDE app here, kolourpaint, and that only in some of the schools
[17:30] <ksteffensen> alksig: we're using the default LDM for login and gnome-fallback for the user sessions.  does launching a single KDE app load all of that 600mb?  or is that only for using plasma or the like as your session?
[17:31] <alkisg> We have the same setup, I think it depends on the app, but no, not all the 600 mb
[17:31] <ksteffensen> got it.  thanks.
[17:41] <ksteffensen> lmk: and higvoltage: kturtle, ktouch, and scribus are all working correctly now.  The specific reason solution sounds like switching QT back to native mode.  But I also added in LDM_DIRECTX=True for overall better performance.  Thank you very much for pointing us in the right direction!