I guess another thing I'm saying is that I don't know whether or not to consider the slow graphics a bug. I brought up video playback because I really think things should work better, and I figure video is something people use commonly. I have no other benchmarks, etc., for comparison, except our own internal tests. So, I can't tell if there might be some library or hardware issue because I don't know what to expect. Maybe this is the best it can do, but I definitely expect something better than what we're seeing. Our client and server hardware is really good, and we're using direct X, so it seems that the thin clients should at least show videos well.
Even if something appears to be a bug, I don't know whether to talk to LTSP, NVIDIA, Ubuntu, the application developers, Xorg, etc. We live on the bleeding edge, using "scientist software," (our own and from others). So, we're used to having to make software work. I'm just trying to learn enough to get a feel for where I have to make a hack and where I need to tell someone else about a problem. On Wed, Feb 27, 2013 at 8:57 PM, Lachele Foley <lf.l...@gmail.com> wrote: > Thanks for the detailed response. That helps. We have already done > what we could find easily, for example setting "LDM_DIRECTX = True". > > We have also experimented with running things as localapps. And, our > clients are generally pretty beefy (quad core, 4 GB RAM, nice graphics > card). The biggest problem, one might think, is getting the > networking to be seamless regardless whether the app is local or > remote. But, we haven't bothered to implement this. We can, of > course, even in our complicated networking environment... keep > reading. > > One reason we really like using thin clients with LTSP is that each > client is just that: a client. It has all the server's resources > available to it. For example, if a deadline is approaching, I'm using > a 24 proc machine with 32 GB of ram. Sure, I'm sharing, but typically > we don't all have crunch time at once. I can start multiple virtual > machines, open a multiple-gigabyte file, etc. This is a good, > economic way to ensure everyone has resources when they need them. If > I could afford to put a 24 processor, 32 GB (or even 12/16) machine > under everyone's desk, I would. > > You mention the decompression happening too soon. I wonder if there > are analogous troubles with other software we use. Our software does > a lot of rendering on the fly. For example, it might project a bunch > of balls and sticks in 3D onto the 2D viewing surface. Is there a way > to tell, without having to interrogate the application, where the > instructions are being sent and executed? Some sort of strace-ish > thing? > > Our main benchmark tests the time required to render an irregular > surface. As a local app, that can happen in 3-4 s. The best time as > a client so far is about 10, which, for most day-to-day stuff we do, > is fine. The trouble is that if we have something large enough to > actually need the extra oomph, then it might be such a large task that > it could fill the 3-4 GB of RAM available on the thin client. One of > the students ran into that not long ago. So, we're back to needing > the resources of the server. And, at that point, that time factor of > 2-3 or more becomes important. > > Also consider virtual machines. Unless they weren't doing much, they > could tax even a good client pretty quickly. This is particularly > true if you have more than one running at once. In this case, having > them run on the server is again a bonus -- you can have sufficient > cpus and memory allocated. Using server resources is especially > important if you can't afford a hot-shot client: if an OS won't run > well enough natively on a client, it sure can't run in a VM as a > localapp. But, video performance suffers a lot when using virtual > machines. Of course, as was our case a year or two a go, choppy > graphics on a VM that works otherwise is better than nice graphics on > a native OS that can barely do anything else. > > Of course, what I'm saying is that we prefer thin clients. If all I > needed was to control a boot image, I would feel differently. But, > what I need is to make big, central resources available to a bunch of > people working as a group. What would it take to make these things > possible? > > > On Wed, Feb 27, 2013 at 7:43 PM, James McQuillan <j...@mcquil.com> wrote: >> 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 >> > > > > -- > :-) Lachele > Lachele Foley > CCRC/UGA > Athens, GA USA -- :-) 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
