I haven't checked any logs recently. But, if there were memory issues, I would expect there to be problems elsewhere. I use one of these clients pretty heavily all day, and there are two other users with clients on the server. This is the only program we've encountered yet on this setup, other than Unity3D, that behaves in any similar way. In both cases, it happens reliably and immediately. I'm pretty sure it's about the video drivers interacting with the new hardware.
Also, if we run VMD as a localapp on the clients, it runs just fine. So, it definitely isn't an issue that's only on the client side. I don't think I can easily do that test for Unity3D. But, I think that's what runs when I log in to the server. In VMD's case, it might be related somehow to VMD's use of CUDA. VMD also runs pretty slowly on our amd machines in general, regardless of OS or client/server/lone-machine status. So, my guess is that whatever it's doing happens at a pretty fundamental level, and there's some issue in the translation between server and client. (The machines I'm mostly talking about here are intel, but we have others.) I've been testing new HP equipment with LTSP for a while. The setup we finally bought has arguably the strangest behavior. I had to use Ubuntu 11.10 just to get it to do anything (details upon request), and then I had to do a lot to get display. In this case, it seemed to be the combination of monitor and card. At first, I could get display from default LTSP configurations if I hooked the new monitor up to an older Nvidia card in an older machine -or- if I hooked an older monitor up to the new Nvidia card/machine (but only if I used a VGA input). But, I couldn't get display to work at all if I hooked the new monitor up to the new card/machine. Skipping some details, I finally installed nvidia-current on server and into the chroot. Then, I got a rudimentary nvidia xorg.conf using a non-X screen. Then, once I got an image at all, I tweaked it with help from nvidia-settings. Here is a list of other video weirdnesses that happened when we upgraded a different server/client set from Natty to Lucid: http://osdir.com/ml/LTSP-cluster-thin-clients/2011-09/msg00000.html Some of those are the HP tests I mentioned above. On Tue, Jan 3, 2012 at 4:55 PM, Jordan Erickson <jerick...@logicalnetworking.net> wrote: > On 01/03/2012 12:49 PM, Lachele Foley (Lists) wrote: > *snip* >> I probably wasn't very clear that the only place I've found a solution >> regarding having a session terminate suddenly and being booted back to >> login had to do with that setting. I had ignored the setting because, >> as you say, with 2+GB of RAM, it seemed unlikey that was the issue. >> But, in desperation I tried it, and much to my surprise, one problem >> (VMD) was fixed by altering it. So, somehow, it's having an effect, >> though I don't think it should. > > > I think you're right with that. Unless you're having HARD-lock issues, > X_RAMPERC probably isn't going to help much. But maybe it's at least a > clue as to why it "fixed" VMD...just a guess, but maybe bad memory? > > Have you examined the logs? > > > Cheers, > Jordan > > > --- >> On Tue, Jan 3, 2012 at 3:09 PM, Jordan Erickson >> <jerick...@logicalnetworking.net> wrote: >>> Hi Lachele, >>> >>> I haven't had my hands in lts.conf for a little while but I think your >>> perception of X_RAMPERC is a little off. >>> >>> You mentioned that "even setting X_RAMPERC to 20 didn't make the default >>> Unity3D session work" - I would imagine not much at all would work if >>> you only allow 20% of your memory to be allocated for the X server on >>> the terminal! >>> >>> Check this out. I don't know if you've been posting here in the recent >>> past so I apologize if I'm not seeing the context.. but I've dealt with >>> X_RAMPERC a lot before regarding older issues with Firefox (pixmap >>> cache....groan). >>> >>> You shouldn't even really worry about X_RAMPERC if you have 2GB+ memory >>> on the terminal side, I would imagine. But if you want to make sure your >>> entire session doesn't hard-lock because of you running out of memory, >>> set it to 95 or something similar, so it will kill any offending >>> application that might be gobbling up memory, before it takes the whole >>> system down with it. >>> >>> >>> ----- >>> >>> _X_RAMPERC_ >>> default ´100´, Percentage of RAM for X server >>> >>> Some programs allocate a large amount of ram in the X.org server >>> running on your thin client. Programs like *Firefox* and *Evince* >>> can >>> use up so much ram, that they eventually exhaust all your physical >>> ram, and NBD swap, causing your thin client to crash. If you find >>> your clients being booted back to a login prompt, or freezing up >>> when viewing certain PDF´s or web pages, this may be the problem. >>> >>> The _X_RAMPERC_ variable stands for X RAM PERCent, and is a number >>> between 0 and 100 that specifies how much of the free space on >>> your >>> thin client X.org is allowed to consume. You´ll generally want to >>> set it at something lower than 100 percent, if you´re having >>> problems. Experimentation has shown a value between 80 and 90 will >>> usually keep the terminal alive. What will then happen is the >>> program consuming the memory will die, as opposed to the thin >>> client itself. If you´re having unexplained terminal problems, >>> specifying: >>> >>> X_RAMPERC = 80 >>> >>> in your lts.conf file may improve things. >>> ----- >>> >>> >>> Again, I hope I'm not out of context and that this info helps. =) >>> >>> >>> Cheers, >>> Jordan >>> >>> >>> >>> >>> On 01/03/2012 08:29 AM, Lachele Foley (Lists) wrote: >>>> I'm really confused about why changing X_RAMPERC fixed one problem, >>>> and if so, why it didn't fix another. >>>> >>>> The issue is that clients with less RAM won't need to have X_RAMPERC >>>> set lower, but clients with more RAM will. There are other >>>> differences, of course -- different hardware, different client image >>>> (64 vs 32). But, it seems odd that a client with 1 GB of RAM can >>>> handle something that a client with 2 or 4 GB can't. >>>> >>>> And, I'm not talking about a system that has other programs eating >>>> memory. I mean (1) boot client, (2) log in, (3) start or start to use >>>> program, (4) back to login immediately. On one machine (loaner, no >>>> longer available for testing), this would cause it: (1) boot (2) log >>>> in (3) open terminal (4) "ltsp-localapps xterm". I'm surprised that >>>> opening a couple terminals could eat that much memory that quickly. I >>>> didn't try resetting X_RAMPERC on that machine because I simply could >>>> not believe that was the problem. I could open and run other programs >>>> -- there were only a few that caused it. When they did, though, they >>>> did so immediately or almost immediately. >>>> >>>> Most recently, the program VMD would cause crash-to-login if its >>>> display window was moved from one monitor to the other. Again, this >>>> is at fresh boot and login, and without having even loaded any files >>>> into VMD. Oddly, running VMD as a localapp on the client worked fine >>>> (and a lot faster). However, I finally decided to try lowering >>>> X_RAMPERC, and, lo-and-behold, VMD stopped crashing when not run >>>> locally. These clients have 4 GB and the server has 32. During these >>>> tests, there was very little load on the server either. Right now, >>>> with three different browsers, each with multiple windows, evince and >>>> a handful of terminals running, that same client says it has 3.37 GB >>>> of its 3.94 GB free (using "free"). I just opened VMD, and that >>>> changed to 3.36 free. We also have several dual-monitor setups on >>>> older equipment that handle this sort of thing just fine, and lots of >>>> other stuff, all at once. >>>> >>>> So, even though setting X_RAMPERC fixed the VMD issue... I wonder if >>>> the problem isn't really somewhere else. >>>> >>>> By the way, even setting X_RAMPERC to 20 didn't make the default >>>> Unity3D session work. It still appears to accept a password, then >>>> makes the theme music, then back to login. Other sessions (2D, XFCE, >>>> LDXE, xterm) work fine. >>>> >>> >>> >>> -- >>> Jordan Erickson (PGP: 0xDA470FF8) >>> LNS: (707) 636-5678 - http://logicalnetworking.net >>> >>> >>> ------------------------------------------------------------------------------ >>> Write once. Port to many. >>> Get the SDK and tools to simplify cross-platform app development. Create >>> new or port existing apps to sell to consumers worldwide. Explore the >>> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join >>> http://p.sf.net/sfu/intel-appdev >>> _____________________________________________________________________ >>> 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 >> >> >> > > > -- > Jordan Erickson (PGP: 0xDA470FF8) > LNS: (707) 636-5678 - http://logicalnetworking.net > > ------------------------------------------------------------------------------ > Write once. Port to many. > Get the SDK and tools to simplify cross-platform app development. Create > new or port existing apps to sell to consumers worldwide. Explore the > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join > http://p.sf.net/sfu/intel-appdev > _____________________________________________________________________ > 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 ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _____________________________________________________________________ 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
