Michal Rybárik
2015-01-17 20:24:21 UTC
Hi folks,
we have been using OpenSUSE 11.3 + LTSP + XDMCP for past 4 years as
office destops, usually serving 5-7 users. Things were working well, but
accidentaly we lost server system image few months ago, and fresh server
had to be installed. We had some issues to make LTSP running on latest
OpenSUSE, so we installed CentOS 6.5 with KDE and LTSP. Now we are using
the same hardware as before, only software versions changed, but things
are MUCH SLOWER now and we cannot find why. Server has a plenty of CPU
and RAM, network is fast enough. Thinclients have 1GHz x86 CPU, 1GB RAM,
SiS VGA (single-head) or ATI Radeon 9200 (dualhead).
After CentOS+LTSP fresh install and first login to thinclient, we
noticed that drawing of simple window (konsole, kate) took around 1
second, user can see window contents drawing line by line. Also
scrolling of window was very slow, it also took around 1 second to
refresh windows content line by line. Setting LDM_DIRECTX=True didn't
helped (but we kept this anyway, as there is no need for ssh tunelling
on local network). Using SCREEN_07=xdmcp instead of =ldm didn't helped
too, problems remained. Finally adding "export QT_GRAPHICSSYSTEM=native"
to /etc/profile fixed this for these KDE/QT apps, but still it seems
that it is quite slower than before.
But there are still some other very trivial actions, that are *VERY*
slow to display, and they can make thinclient almost unresponsive:
1) LibreOffice Calc selection -- start oocalc, select few cells, push
Ctrl-C => dashed border is drawn around all selected cells, and the
dashes are moving (redrawing) continously. If one or two cells are
selected, and there are not so many dashes on the screen, thinclient
responses are quite slower (window switching, scrolling, typing, etc).
But if more cells are selected (and there are more moving dashes around
them), thinclient can became almost unresponsive, and it may take half
minute or minute to get response to any action (clicking, ...). To get
responsivity back, user has to select one cell then (it may take a loong
time!!), press Ctrl-C, and then moving dashed line is reduced, and
thinclient responsivity is back...
2) rdesktop / xfreerdp - This was extremely fast before, very similar
like sitting in front of real Windows machine. Now it is very very bad,
moreless unusable, I think that rdesktop via 1 Mbit/s line is faster
than this. Simple window on remote rdesktop computer, redrawind its
contents continously, for example Task Manager (taskmgr), can make
thinclient unresponsive. One day I let taskmgr running for a few
minutes, and my thinclient became almost unusable (it took few minutes
to get reaction to any action). Meanwhile, LTSP server and other
thinclients were acting normally. We shutted down windows machine (which
was running taskmgr), and my thinclient remained displaying its screen
and refreshing taskmgr for more than 3 minutes after windows shutdown
(yes, windows machine was powered down for minutes, and thinclient was
still showing and refreshing its screen, and it was impossible to do any
action on thinclient). Then the rdesktop disappeared suddenly, and
thinclient got its responsivity back.
Thanks to this issue, we found that that weird things are caused by high
CPU load on thinclient. Usually it is up to 1.00, but with
oocalc+selection or rdesktop+taskmgr, load can go 30.00 and more in a
minute or a few. "top" and "htop" says, that it is Xorg who is eating
CPU. But why? I hope that 1 GHz should be enough for displaying moving
dashed line, or refreshing taskmgr each second... :o/ This worked
before, without any issues. BTW, directly on the ltsp server screen (not
using thinclient), this is OK, no lagging, no problems...
We also noticed that also parts of the screen are mismatched sometimes
(usually where user type or scroll), for example part of the text line
is suddenly in a moment replaced with part of another text line
(upper/lower row).. It seems to me like some paerts of the screen are
dometimes not redrawn, or rare redrawn but at wrong position. It happens
on Firefox, kate (kde editor), Libreoffice, Geany, and many other apps
too...
This all happens on both thinclient configurations - with SiS VGA (where
no DRI is detected), and also with ATI Radeon (DRI detected and used,
Xorg.7.log says that).
At konsole commandline (on ltsp server, started from thinclient) when I
run "glxinfo | grep render" I see
direct rendering: No (LIBGL_ALWAYS_INDIRECT set)
OpenGL renderer string: Mesa DRI R200 (RV280 5964) TCL DRI2
If I unset LIBGL_ALWAYS_INDIRECT then I see
direct rendering: Yes
OpenGL renderer string: Software Rasterizer
GL_EXT_vertex_array_bgra, GL_NV_conditional_render,
GL_ARB_debug_output,
On LTSP server side in its Xorg.*.log I see that DRI fails and software
renderer is used. But I'm not sure if it is an issue (because nobody is
logged on LTSP server durectly, all users are using thinclients).
We tried also upgrade to CentOS 6.6, and also CentOS 6.6. fresh install,
but it didn't help.
What could cause our problems? Any idea?
Many thanks for hints & replies...
--
Michal Rybarik
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_____________________________________________________________________
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
we have been using OpenSUSE 11.3 + LTSP + XDMCP for past 4 years as
office destops, usually serving 5-7 users. Things were working well, but
accidentaly we lost server system image few months ago, and fresh server
had to be installed. We had some issues to make LTSP running on latest
OpenSUSE, so we installed CentOS 6.5 with KDE and LTSP. Now we are using
the same hardware as before, only software versions changed, but things
are MUCH SLOWER now and we cannot find why. Server has a plenty of CPU
and RAM, network is fast enough. Thinclients have 1GHz x86 CPU, 1GB RAM,
SiS VGA (single-head) or ATI Radeon 9200 (dualhead).
After CentOS+LTSP fresh install and first login to thinclient, we
noticed that drawing of simple window (konsole, kate) took around 1
second, user can see window contents drawing line by line. Also
scrolling of window was very slow, it also took around 1 second to
refresh windows content line by line. Setting LDM_DIRECTX=True didn't
helped (but we kept this anyway, as there is no need for ssh tunelling
on local network). Using SCREEN_07=xdmcp instead of =ldm didn't helped
too, problems remained. Finally adding "export QT_GRAPHICSSYSTEM=native"
to /etc/profile fixed this for these KDE/QT apps, but still it seems
that it is quite slower than before.
But there are still some other very trivial actions, that are *VERY*
slow to display, and they can make thinclient almost unresponsive:
1) LibreOffice Calc selection -- start oocalc, select few cells, push
Ctrl-C => dashed border is drawn around all selected cells, and the
dashes are moving (redrawing) continously. If one or two cells are
selected, and there are not so many dashes on the screen, thinclient
responses are quite slower (window switching, scrolling, typing, etc).
But if more cells are selected (and there are more moving dashes around
them), thinclient can became almost unresponsive, and it may take half
minute or minute to get response to any action (clicking, ...). To get
responsivity back, user has to select one cell then (it may take a loong
time!!), press Ctrl-C, and then moving dashed line is reduced, and
thinclient responsivity is back...
2) rdesktop / xfreerdp - This was extremely fast before, very similar
like sitting in front of real Windows machine. Now it is very very bad,
moreless unusable, I think that rdesktop via 1 Mbit/s line is faster
than this. Simple window on remote rdesktop computer, redrawind its
contents continously, for example Task Manager (taskmgr), can make
thinclient unresponsive. One day I let taskmgr running for a few
minutes, and my thinclient became almost unusable (it took few minutes
to get reaction to any action). Meanwhile, LTSP server and other
thinclients were acting normally. We shutted down windows machine (which
was running taskmgr), and my thinclient remained displaying its screen
and refreshing taskmgr for more than 3 minutes after windows shutdown
(yes, windows machine was powered down for minutes, and thinclient was
still showing and refreshing its screen, and it was impossible to do any
action on thinclient). Then the rdesktop disappeared suddenly, and
thinclient got its responsivity back.
Thanks to this issue, we found that that weird things are caused by high
CPU load on thinclient. Usually it is up to 1.00, but with
oocalc+selection or rdesktop+taskmgr, load can go 30.00 and more in a
minute or a few. "top" and "htop" says, that it is Xorg who is eating
CPU. But why? I hope that 1 GHz should be enough for displaying moving
dashed line, or refreshing taskmgr each second... :o/ This worked
before, without any issues. BTW, directly on the ltsp server screen (not
using thinclient), this is OK, no lagging, no problems...
We also noticed that also parts of the screen are mismatched sometimes
(usually where user type or scroll), for example part of the text line
is suddenly in a moment replaced with part of another text line
(upper/lower row).. It seems to me like some paerts of the screen are
dometimes not redrawn, or rare redrawn but at wrong position. It happens
on Firefox, kate (kde editor), Libreoffice, Geany, and many other apps
too...
This all happens on both thinclient configurations - with SiS VGA (where
no DRI is detected), and also with ATI Radeon (DRI detected and used,
Xorg.7.log says that).
At konsole commandline (on ltsp server, started from thinclient) when I
run "glxinfo | grep render" I see
direct rendering: No (LIBGL_ALWAYS_INDIRECT set)
OpenGL renderer string: Mesa DRI R200 (RV280 5964) TCL DRI2
If I unset LIBGL_ALWAYS_INDIRECT then I see
direct rendering: Yes
OpenGL renderer string: Software Rasterizer
GL_EXT_vertex_array_bgra, GL_NV_conditional_render,
GL_ARB_debug_output,
On LTSP server side in its Xorg.*.log I see that DRI fails and software
renderer is used. But I'm not sure if it is an issue (because nobody is
logged on LTSP server durectly, all users are using thinclients).
We tried also upgrade to CentOS 6.6, and also CentOS 6.6. fresh install,
but it didn't help.
What could cause our problems? Any idea?
Many thanks for hints & replies...
--
Michal Rybarik
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_____________________________________________________________________
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