Running multiple instances Small Question

I run SL under Ubuntu 7.10, i followed the info at the below link all works great. The only issue is when i log off one of my accounts, the typing sound stops on the remaining viewer everything else is fine...is there a way to sort this?

http://wiki.secondlife.com/wiki/Help:Running_multiple_instances_of_the_Second_Life_client

I use two account for testing, its not a big issue but it would be cool if the typing sound stayed.

This may not be EXACTLY your issue, but I have had problems with multiple SL's unless I also specify a port, different for each SL Viewer.

I start one SL with "-multiple -port 13002" as an additional parameter, and the other one as "-multiple -port 13004". As far as I know, ports 13000 up to 13010 work fine. I have not tested beyond this.

The issues I have seen here when separate ports are not specified are lockups of SL, or one SL viewer getting everything and the other nothing (FPS wise).

From the sound of it, that is not directly so in your case; it rather sounds like a sound issue. However, since the above "-port ..." has created so many different types of issue on my setup, it may be worth trying anyway.

Linux seems to be particularly sensitive to this parameter; Windows sems to be OK without the "-port..." when -multiple is used.

I only solved this by using ESD and starting this sound daemon as root on startup and not automatic when running the sl client.

But another question: did anyone succeed running more than 2 ( in actual RC more than 3) instances? Any resource seems locked. I lowered graphic memory assigned but this did not fit this issue. A 3rd ( or 4th) client only loads and runs in slow-motion - so slow that login runs into timeout.
There is enough ram in the machine, so this can't be the limit

This is a great question for people living on the limit

No idea why it should lock, but the big locking issue could be, Who Talks to the Graphic Card Memory and CPU?

I know that SOME issues exist with all SL instances using the same cache - this also would have locking issues, which may not be apparent with only (!) 2 SL instances running, but become inevitable with 3.

Can you try starting the instances with different cache directories? Cache areas often have a control block which gets an exclusive lock when the contents are being updated, and is released (in a clean application) when the write operation is complete. I presume the "-multiple" parameter does something like this, in addition to handling the "lock" file differently. But with 3 instances and one cache this may be a deadlock of sorts on the control block.

If you have any kind of real-time processor load indicator (the KDE System Monitor panel applet is good; GKrellM is nice for detailed and highly configurable system monitoring), you'll note that whenever the SL viewer is running and on-screen, it keeps one full CPU (or core) 100% busy. So if you have a dual-core CPU, you can keep two running more or less (probably a little less) actively but as soon as you have more SL viewers than CPUs or cores, then they're going to contend and the net result will be poor (probably unacceptable and unusable) level of performance from any one of the viewers.


Rudy

Good point. I have had 2 SLs running (slowly) on my system, if I use "-multiple -port 13xxx"; however a TOTAL lockup is probably something other than a lack of CPU power. I have seen my second SL lock up like this when I have forgotten to allocate a separate port.

There was a post somewhere in this forum, indication that SL does not REQUIRE the 100% CPU it gets, merely that it does not release the CPU to the system, in order to optimize its performance, so 100% CPU will be shown. I am not so sure this is true, since I do get roughly half the performance per viewer when I have two running. By extension, I should then get one third or so with three running, I guess. If a total freeze comes up, it looks to me like a resource locking problem, either software (e.g. cache control block) or hardware (Graphics Card has a similar problem).

xosview is what I use to watch performance, and the "load" value is often at 2 (one cpu fully loaded, and enough for one more CPU, though this simplification will get me shot down since it ignores the very intelligent priorities with the Linux Run Stack ) with one SL running. I have seen values up to 6 when KDE starts. If load goes above 4 my system is very sluggish, but still runs. I have a single CPU, see my signature.

Load in a simplified form is "no of CPUs the system load could keep busy". Now hit me

I guess you just have to fiddle.

Well, one can argue whether or not SL absolutely needs the CPU cycles it takes, as it's coded, it appears that they're not really optional.

And I agree, too, that gross failures like system lock-ups are a sign of some real problem. It could be a deadlock or it could be something I've heard others report, namely that heavy load makes their systems halt. I've experienced it, too, but only when I've been excessive in my overclocking. Others report it's poor thermal regulation (often with quad-core processors). Have you over-clocked your system?




Unfortunately, the so-called "load average" is an extremely misleading metric. I recommend people ignore it. However, xosview does a good job of showing things that do matter, like instantaneous CPU utilization, interrupt and disk or network I/O rates.

Rudy

Just to be irritating, here is a summary and some links to load averages in Linux.

Load averages don't say "nothing" but can of course be misleading. If you know exactly WHAT the load average is, you can see that it is an indicator and not an exact pointer (like for example cpu utilization is).

Quote, here the three load averages referred to are the ones shown in 'top':

"In short it is the average sum of the number of processes waiting in the run-queue plus the number currently executing over 1, 5, and 15 minute time periods.

It’s calculated like this: load(t) = load(t - 1) e^(-5/60m) + n (1 - e^(-5/60m))
(at least in Linux)..." http://nosheep.net/story/tag/unix/

Or, more useful (cos it's less accurate ):

"So what does this mean about your system?

Well, for a quick example let’s consider the output below. The load average of a system can typically be found by running top or uptime and users typically don’t need any special privileges for these commands.

load averages: 2.43, 2.96, 3.41

Here we see the one minute load average is 2.43, five minute is 2.96, and fifteen minute load average is 3.41.

Here are some conclusions we can draw from this.
On average, over the past one minute there have been 2.43 processes running or waiting for a resource
Overall the load is on a down-trend since the average number of processes running or waiting in the past minute (2.43) is lower than the average running or waiting over the past 5 minutes (2.96) and 15 minutes (3.41)
This system is busy, but we cannot conclude how busy solely from load averages.

It is important here to mention that the load average does not take into account the number of processes. Another critical detail is that processes could be waiting for any number of things including CPU, disk, or network.

So what we do know is that a system that has a load average significantly higher than the number of CPUs is probably pretty busy, or bogged down by some bottleneck. Conversely a system which has a load average significantly lower than the number of CPUs is probably doing just fine."

http://www.lifeaftercoffee.com/2006/03/13/unix-load-averages-explained/

In short, load can indicate (but not state definitely) if your system is heavily loaded.

The load value is limited, misleading and can be VERY useful

Back to the question...

There is definitely no lack of CPU or RAM

There are 3 running instances on inactive virtual screens, top shows the following:

top - 08:32:50 up 16 days, 11:40, 7 users, load average: 1.13, 1.26, 1.31
Tasks: 128 total, 1 running, 126 sleeping, 0 stopped, 1 zombie
Cpu0 : 21.8%us, 0.4%sy, 0.0%ni, 76.7%id, 0.4%wa, 0.8%hi, 0.0%si, 0.0%st
Cpu1 : 18.2%us, 0.8%sy, 0.0%ni, 81.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 4052912k total, 4025020k used, 27892k free, 130096k buffers
Swap: 3911788k total, 98380k used, 3813408k free, 535208k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
25262 papa 15 0 1221m 1.0g 77m S 18 27.0 147:49.87 do-not-directly
25323 papa 15 0 726m 597m 65m S 13 15.1 83:23.61 do-not-directly
25292 papa 15 0 738m 600m 70m S 8 15.2 45:06.67 do-not-directly



Every instance hast his own */.secondlifexx including own cache
Every instance has set a different port
There is set -multiple in every instance.
It makes no difference if I deactivate sound with removing # in start script a the sound variables

Every instance runs fast when activated (15-70fps depending on region)

If I try to run one more instance, it lasts about 5 minutes until logon screen appears.
On display is seems every pixel is drawn manually...
The other instances keep running fast.

So it seems that the 4th instance tries to get any locked resource again and again without doing any harm to to previous running instances. There is no hint in the any logfile (system, X, SL...)

Any other application (konqeror, firefox, openoffice...) start and runs fast and with no problem.

I have no idea what happens..

Sorry about hijacking the thread concerning Load.

How is the graphics memory set in each SL instance? To run two SL's I give each 240 MB graphic memory since I only have 512 MB on my graphic card, and run other stauff that uses graphic memory (opera with 10 tabs open) at the same time.

Typing "ctrl shift 3" will show what your graphics cache is like in each instance. With my setup, I sometimes get the "bars" yellow until SL throws stuff out of cache. When SL starts cleaning up its texture cache, I can get momentory lock up.

Sorry that I cannot give any particularly inspired Magic Bullets. My brain is normally in a "no buiild" area regarding Magic Bullets

I made several different settings including to give every instance the miminum memory.

When SL window is miminized or in an incactive virtual screen, grafic memory is completely released and reloaded from system ram when reactivated.

The 4th instance cannot be logged in (login runs so slow that is times out), so the texture console cannot be viewed there.

I think, there must be another resource (e.g. shaders) that is not released by SL/GL/driver when switching the sl window in background.

I could only test with NVidia (6600, 7600, 7900) and hat the same effekt every time.

It would be interesting and a hint to know if it also happens with ATI

It would also be interesting what happens on Windows/Mac

Maybe there's a Zapruder - film of a grassy knoll in the area where the bullets might spray from ?

... sorry .. i'm silly...