I'm pretty sure I get X_RAMPERC. Maybe I didn't explain the situation very well. Or, maybe what I said sounded unbelievable, and I agree it sounds that way, so you didn't imagine I meant it.
> 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! Precisely... but.... It won't work at 100% either. Or at 90, 80, 50 or 20. Every time, regardless what I do, it accepts the login creds, plays the music, and boots me back to login. The issue, best I can tell, is related to our fancy new hardware. But, I think something also got broken in ltsp between 10.0.4 and 11.04, and became slightly unbroken in 11.10 (but that's an even longer story). 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. On Tue, Jan 3, 2012 at 3:09 PM, Jordan Erickson <[email protected]> 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 -- :-) 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
