New SL Optional Viewer

Actually this is not entirely true. The overall temperature of your box will go down with the lid off, but what you want is a regulated flow of air from one side of the box to the other. With the lid off you get a chaotic flow which in the long run is not as good as a directed flow. Adding a fan at the right spot inside of the box does a better job with this.

Oh of course, but it's a good way to rule out poor case ventilation as the cause of overheating.

I must admit, i don't expect overheating to be the problem.
Maybe would be of the graphics card, since it's passively cooled, but should get the new GeForce 6600GT tomorrow, which is actively cooled.

As for /tmp running out of space: have 61GB available on that partition, so that should definitly not be the problem.

And yes, it is the native client.

keep an ssh running, and usually you can ssh in from a laptop and reboot X.

Oh, no problem there, I can login via ssh from my laptop, but still I have to kill -9 X and restart from scratch. This is not pleasant with mail, chat, browser and other applications running while X crashes.

I looked at my own client today, and found the following:

The new client uses a whopping 636 MByte of Ram (592 MB Resident) alone! (Value from top)

This is the most I have ever seen from the SL client!

So with 512 MB of RAM (and how much swap?), you are going to run out of memory. The rattling of the disk could be the system writing stuff out to swap, to try to get more real memory.

After TPing to a new place, and waiting for textures to load, I get the SL Linux Alpha Client using 883/826 Mbyte.

Houston, I think we have a problem...

I have 512 Mb of RAM but thought this client is quicker. I do not have any hacks running, though. (except changing the RAM of the video card, which I dont see as areal hack)

I am hunting for the reason my SL Linux Alpha uses so much memory. At the moment my primes suspect is "shiny", which I have turned on even though it does not work. I will take it out tonight, and see how it turns out.

The HUGE amount of memory used does not appear to be typical.

Sorry if I planted a red herring here

to be more exact at a more quite place it takes about 200+x MB of RAM and 80% of CPU. This is a 1,2 Ghz computer with 512 MB and a Geforce 5200fx.

Terrain detail is set to "Some".

This is EXACTLY what I get when I use my Intel Celeron 2.2 GHz.

It seems to be specific to AMD. Is it related to 3DNow! maybe? Or SL checks for something, that gives a different result with the AMD Chips?

What metric are you using to measure RAM usage? I would suggest the "writeable/private" report from the pmap command; it sounds like you are incorrectly reporting the virtual set size or resident set size from ps or top.

The values are from top; this has been reliable in the past, and is a good guide, since it agrees with what I see in XOsview. The computer also starts paging things out to swap - I have seen 90 MB in swap at one stage (XOsview).

But the problem is resolved...

1.9 handles the draw distance differently; I set my draw distance down to 128 from 512, and I have perfectly normal memory usage now, even after repeated TPs to texture intensive places. The flood of bad packets when I TP somewhere has gone too. It seems my system was being overloaded by that draw distance.

But thanks for that tip If I was trying to debug 1.9 it would be very useful; but I just want SL to run as it is presented.

Sorry I didn't end this off, I forgot this thread also had stuff on memory usage in it

Oh, wow. I think standard is 64. A good idea is always to st values back to standard, especially if you do a value that is nearly 10x of the default.


Vinci

My oops...

It was running fine with 1.8, so I kind of forgot about it