Hi Helmut, we have same performance problems as you. Everything was working well on older distributions for long years (we used OpenSuse 11.3 past years). But when installing newer distributions (Kubuntu 14.04, CentOS 6), graphics is very very slow, on the same hardware and same network as before. Very simple graphics changes now uses 100% CPU on 1GHz thin client, and load goes to 30.00 and more in a short while. Thin client with dualcore i5 CPU is now slower, than 350 MHz PII was before.
There are some simple graphics operations that kills performance very drastically - for example in OpenOffice Calc if user selects more cells and press Ctrl-C (copy), moving dashes are displayed around selection, and these moving dashes makes thin client almost unresponsive (because of very high CPU usage). Setting QT_GRAPHICSSYSTEM=native partially fixes problem for QT applications. Fullscreen Konsole window is redrawn in ~5 seconds without this setting, and in <1 second with it. But we are unable to fix other operations (for example OpenOffice selection mentioned above). I can say that this appies to - all graphics chipsets that we have in thinclients (SiS, Radeon 280, intel HD 4000), no difference between chipsets - both LDM and XDMCP method of communication - both Kubuntu 14.04 and Centos 6 We are trying to find solution for more than 4 months, but still no luck. All suggestions are welcome... -- Michal Rybarik Dňa 02/16/2015 o 01:27 PM Helmut Lichtenberg napísal(a): > James, Karl, > thanks for your replies. > > James McQuillan schrieb am 13.02.2015 14:53: >> My first guess would be the graphics drivers that have been automatically >> chosen for those thin clients. >> >> If it's using the generic driver instead of the specific driver that's best >> for each chipset, you'll see graphic performance like you describe. >> >> Perhaps you can get a shell running on the clients and look at the >> /var/log/Xorg.0.log file. That'll show you >> which driver was chosen. > I think you are right that it's some generic problem as it spreads across > several distinct hardware. > I have access to the /var/log/Xorg.7.log on the clients (via ssh). X uses the > specific drivers (OpenChrome for VIA-Chips, Intel, etc.). > > But looking into the logs I found messages like this: > [ 347.509] (II) LoadModule: "glx" > [ 347.509] (II) Loading /usr/lib/xorg/modules/linux/libglx.so > [ 347.553] (II) Module glx: vendor="NVIDIA Corporation" > [ 347.553] (II) NVIDIA GLX Module 340.65 Tue Dec 2 09:02:32 PST 2014 > [ 347.553] Loading extension GLX > [ 347.712] (EE) Failed to initialize GLX extension (Compatible NVIDIA X > driver not found) > > This happened on an Intel board. > I never dived deeply into this graphics stuff (and never wanted to) and > therefore have to learn some basics like: > - OpenGL is a hardware- and platformindependant Interface for 3D-Graphics. > - GLX ist the layer between OpenGL and X-Windows > - DRI provides hardware acceleration for OpenGL. > > On Debian, there are currently 3 GLX providers: mesa, nvidia, and fglrx. Only > mesa and nvidia have been installed in the image. I added the fglrx (for AMD > boards) and changed the glx-diversions from nvidia (hence the above error > message) to mesa with > > update-alternatives --config glx > > At least on an Intel-based client (openthinclient, I didn't yet test others), > the Xorg.7.log file now show this: > > (LTSP)root@otc5:/~# grep -i glx /var/log/Xorg.7.log > [ 2187.600] (II) LoadModule: "glx" > [ 2187.601] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so > [ 2187.602] (II) Module glx: vendor="X.Org Foundation" > [ 2187.602] (==) AIGLX enabled > [ 2187.602] Loading extension GLX > [ 2188.837] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer > [ 2188.837] (II) AIGLX: enabled GLX_INTEL_swap_event > [ 2188.837] (II) AIGLX: enabled GLX_ARB_create_context > [ 2188.837] (II) AIGLX: enabled GLX_ARB_create_context_profile > [ 2188.837] (II) AIGLX: enabled GLX_EXT_create_context_es2_profile > [ 2188.837] (II) AIGLX: enabled GLX_SGI_swap_control and > GLX_MESA_swap_control > [ 2188.837] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects > [ 2188.837] (II) AIGLX: Loaded and initialized i915 > [ 2188.837] (II) GLX: Initialized DRI2 GL provider for screen 0 > > Seems to look better, but the windows behave as sluggish as before. > > Karl Duc - Vormingplus regio Brugge schrieb am 13.02.2015 16:41: >> could it be a QT-problem? >> check https://en.opensuse.org/SDB:KIWI-LTSP_troubleshooting, at the bottom >> of the >> page: >> "In case of slow KDE applications on the thinclients (Qt apps like Dolphin, >> Kate, etc...), you have to modify the rendering of the Qt graphics system. >> One way to do this is create a file /etc/profile.local with following in it >> >> export QT_GRAPHICSSYSTEM=native >> >> Restart the thinclient and enjoy a fast ride" >> this solved a similar speed-problem for us, a year ago, using opensuse and >> kde > When I tried to implement your hint, I found that I've already done it in Nov. > 2014. Seems you already wrote it last year on the list. :^) > But this also means, it doesn't help that much. > > Again I'm running out of ideas. > > Thanks for you help > Helmut > ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.freenode.net
