Lachele,
I'll try and explain how the graphics works in a thin client environment.
A typical LTSP thin client is just a small computer with a monitor,
keyboard and mouse attached to it.
The thin client has a video card that the monitor is plugged into, and
usually USB or PS2 ports for the keyboard and mouse.
The Xserver is sort of the ring leader. It has control of the video
card/monitor, keyboard and mouse.
Meanwhile, the "client applications", such as Firefox, Unity, LibreOffice,
... are programs running on the server machine.
These client applications open a connection across the network to the
Xserver on the thin client.
Using the X protocol, the application sends instructions to the Xserver to
do things, such as 'display a rectangle of a certain size at a specific
location' or 'display this string of text using a courier font at a
location'.
Information also goes the other way too. That is, if you press a key on
the keyboard or move the mouse, the Xserver will see that and turn those
into events that get sent across the network back to the client application.
The client application is in an event loop, receiving those events and
handling them. It's hard to believe that some of the most awesome things
you see an application do are really just lots and lots of very simple
primitive things, like mouse-move, draw-rectangle, key-pressed, ...
For simple things, like displaying text or entering text into fields in a
form in a web browser, this works really well. It's not much traffic on
the network, so the performance is more than adequate.
When you want to do things like play a video, the client application
(Firefox?) running on the server, fetches the compressed stream (MPEG-4,
H.264, WAV, Flash, Quicktime and many others) and turns it into frames of a
video image. Then, each of those frames get sent across the network to the
Xserver so that they can be displayed on the monitor. This is where the
performance can really be bad. The video stream is getting decompressed
too soon and then sent over the network in an un-compressed format. On top
of that, LTSP tunnels all X traffic through SSH which encrypts the data
over the wire. While this is great for security, it's terrible for
performance. There is a way to disable the X over SSH by setting
"LDM_DIRECTX = True" in the lts.conf file.
It would be MUCH better to send that compressed video stream all the way to
the thin client, and do the decompressing there, just before it gets sent
to the monitor. But, to do that, you'd need to run your application on the
thin client, instead of on the server. And, this requires more ram and a
more powerful CPU on the thin client. Fortunately, there's some very
powerful thin clients available that have more than enough power to handle
this.
As for fonts, when a certain font is requested, it's the client
application that is asking the Xserver to display that font. So, the
Xserver needs that font. There's a few ways do make sure the Xserver has
access to the font. One way is to install the desired fonts on the thin
client so the Xserver can just open the file and load the fonts in.
Another way is to use a Font server. XFS is a font server. It runs on
the server. The Xserver makes a connection over the network to the Font
server and asks for the fonts to be sent over. I prefer to install the
fonts locally on the thin client, rather than using a font server. I've had
my share of font servers dying, leaving the Xserver hung, waiting to get
the fonts it needs. There's also client-side fonts that get rendered where
the application runs and then get sent down the wire to the thin client.
So really, your fonts probably need to be installed on both the server and
on the thin client.
The X window system was designed from the ground up to be a network
transparent graphics system. Without that capability, LTSP probably would
never have existed.
When you run Linux on a standalone computer, like your laptop or a
traditional desktop computer (not a thin client), The client applications
and the Xserver still work in very much the same way. That is, they run as
separate processes that talk to each other through a network. Only in this
case, it's not an Ethernet network. It's using UNIX sockets instead. These
can be much faster, as there's fewer layers of software to go through, and
no physical network at all.
There's been some attempts at optimizing X by using shared memory. The
problem is, to use shared memory between the client application and the
Xserver, both the Xclient and Xserver need to be running on the same
machine! No more network transparency. This is possibly what you've
bumped into when you've seen applications trying to access the servers
video card instead of the thin clients video card.
I've been focusing most of my rather limited time on running things on the
thin client. To me, everything is moving towards being web-based and the
thin client is becoming a platform for running a web browser. Running the
browser locally makes some things much better. Sound and video perform
very well this way. But, it brings new challenges, like printing. If run
the browser on the thin client, you need to also have a printing sub-system
installed like CUPS.
Also, where's the users home directory? Probably on the server, which
means you need to use NFS or sshfs to have access to it.
I should note that what I've just described in the last paragraph is really
just a fat client.
If you've got powerful enough thin clients, moving the processing down to
the thin client can really boost the number of thin clients that a single
server can support. basically, the server is just a boot server. A decent
server should be able to handle hundreds of thin clients.
I hope my rather long-winded explanation helps.
Jim McQuillan
j...@ltsp.org
On Wed, Feb 27, 2013 at 6:19 PM, Lachele Foley <lf.l...@gmail.com> wrote:
> In our lab, we most often have to diagnose and fix video and graphics
> issues. By the way, if we can help as a testing environment, let us
> know. We push the technology pretty hard and have interest in making
> LTSP work better.
>
> Can you explain how the division of video/graphics is handled? More
> specifically, what I wonder is whether the graphics/video division of
> labor is determined by (a) the ltsp software, (b) the operating
> system, (c) the program that is running or (d) something else or a
> combination of those. I am speaking of thin clients, here (not fat),
> and we have been using Ubuntu, but are considering other distros.
>
> I have gotten the impression that it all happens (or is supposed to
> happen) server-side and the video gets pushed out to the client. But,
> that is clearly not always the case, so I misunderstood or something.
> By the way I know very little about how graphics works, and even less
> about graphics in ltsp, but obviously I need to understand.
>
> For example, I just now posted a solution about xfig, where the
> program is running on the server, but the fonts must be installed in
> the client chroot. That isn't totally a video/graphics problem, but
> the rendered fonts are. Also, I made this post recently which is very
> much about graphics:
> http://sourceforge.net/mailarchive/message.php?msg_id=30473657 I
> wonder if the problem there might somehow be analogous to the fonts
> issue, and how I might go about finding it.
>
> >From error messages we get, it sometimes seems that the programs (e.g.
> chimera or vmd in the post linked above) are attempting to access the
> local video card and/or OS directly. But, it seems they get confused,
> as if sometimes they see the server's card and drivers, and sometimes
> they see the client's. With the font issue, the xfig program is not
> installed in the client, but it requires the fonts to be in the client
> chroot, despite being run from the server, so some part of that
> program sees and queries the client OS.
>
> The following is of far less concern practically, but makes another
> good example: youtube and other web-based videos. Video transfers
> very badly to thin clients. Everything else about a machine might
> improve once it is a client as opposed to a separate machine, but the
> video often gets worse -- all choppy and hard to view, particularly if
> high resolution. If videos were the only thing, we could do without
> watching videos. But, we need good graphics for other reasons.
>
> By the way, hardware is not a limitation here. We're a computational
> chemistry lab, so we have GigE connections and hot-shot graphics cards
> with plenty of processor and ram on server and client, and we've tried
> permutations of drivers and such. We've even made sure the time
> between client and server is ntp-sync'd. Regarding the hardware, I've
> checked atop in the servers and clients, too, and they aren't being
> maxed out (ethernet, cpu, memory).
>
> I keep thinking there must be some configuration or installation issue
> that will solve this. I just don't know what.
>
> --
> :-) Lachele
> Lachele Foley
> CCRC/UGA
> Athens, GA USA
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _____________________________________________________________________
> 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
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_____________________________________________________________________
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
