Too many live music venues lagging....

[Mankind Tracer]

As a live performer since 2006, I've seen many changes in the quality of Sl. It used to be getting 100 people on a sim, and have them STAY there, without crashing and minimal lagging, was not a problem.

 

Over the past year or two this has become increasingly worse and increasingly more and more frustrating. Now when 30-40 people are on a sim while I'm performing, many crash, public chat is horribly laggy, people cant move, cant dance and as the performer on stage, I am running more programs and using up more resources. So having SL be so unstable is causing even MORE strain on my system's resources. 

 

This has been going on for far too long and I would very much like to see some effort being made to either upgrade the SL servers and in the very least, take the highest traffic venues and locations and put them on a more stable server.

 

The SL music community has grown so much since 2006. SL is a great place for artists to come perform, or even just have fun singing to tracks, having karaoke contests, etc. But when the platform is ridiculously unstable, the fun is completely lost as is the vibe of the events.

 

What's being done?

[Mankind Tracer]

As a live performer since 2006, I've seen many changes in the quality of Sl. It used to be getting 100 people on a sim, and have them STAY there, without crashing and minimal lagging, was not a problem.

 

Over the past year or two this has become increasingly worse and increasingly more and more frustrating. Now when 30-40 people are on a sim while I'm performing, many crash, public chat is horribly laggy, people cant move, cant dance and as the performer on stage, I am running more programs and using up more resources. So having SL be so unstable is causing even MORE strain on my system's resources. 

 

This has been going on for far too long and I would very much like to see some effort being made to either upgrade the SL servers and in the very least, take the highest traffic venues and locations and put them on a more stable server.

 

The SL music community has grown so much since 2006. SL is a great place for artists to come perform, or even just have fun singing to tracks, having karaoke contests, etc. But when the platform is ridiculously unstable, the fun is completely lost as is the vibe of the events.

 

What's being done?

[dd Temin]

Here is a test  you can do...that may help to analyze this issue and some simple advice.

Before doing a Live performance,  visit that region /sim  where the performance will be done and  open the VIEW, Statistics window  and  scroll  down to the  section called  "Time"  and click on TIME   to open Time details.  look for 2 parameters called  "Script time" and "Spare time" . 

If the sim/region has more than 10 ms of Script Time  and less than 10 ms of Spare time.....you can be certain that if you bring 30 Avatars to this region during the performance...it will be very laggy.

Ideally  you want to do  your performances in in a region with low Script Time  and lots of Spare Time.

Regions with very high texture texture counts will also  "seem " more laggy  to many of the  30 avatars.

And of course  it all depends on  how many active scripts each of those 30 avatars is wearing as this further degrades sim performance.

Also watch out for regions using / rezzing lots of Temporary objects,( another source of  apparent lag).

Sometimes  we forget  to take all these factors into consideration .

I welcome any other thoughts or opinions.........These are just my personal observations as Estate manager of  3 sims.

[Ayesha Askham]

Mankind and dd

There is a problem and it does not have a simple solution.  The fact of the matter is that the render pipeline of SL is now far more complex than it was even two years ago, let alone 4 or 5.

Each improvement to render quality in SL brings the need for more and more sim-client communication: SSA was an attempt to lessen this, but it is far too little, too late.

The flow down that comms pathway is not fast enough now to carry all the information needed to render SL at the quality that most of us have come to expect, and when that demand exceeds the capacity of the server to supply it, problems will inevitably arise.

I do not have a solution, nor am I sure that one exists.

[Drake1 Nightfire]

there is a very simple solution.. play on a flat empty sim. Have people take off AOs, huds, and scripted items. After all, they are there for the music, not the sim. When going to live shows you should always descript as much as possible, wear non flexi hair and clothing.

just my 2 cents.

[Cincia Singh]

It's worth noting than most, but not all, lag is client side. It's been ages since a region crashed from under me, but staring at 40+ avatars all wearing flexi and HUDs is bound to cause viewer lag except on the most high end computers. It gets worse for people who set their draw distance and/or bandwidth high. There are certain realities in SL and denying them reduces the fun for everyone.

[Ayesha Askham]

Drake

Your solution is in its concept simple but the application, or getting the solution applied is far less simple. Most avas are the products of ignorantly elaborate work by their RL owners, and suggestions that they simplify them simply meets with blank refusal to cooperate.

Cincia

In 2010 use of flexi did not seem to cause a significant issue.  You are correct in that sims rarely crash now, even though large numbers of avatars are on them, though it DOES still occur, especially if, as seems all too common, certain maleficent individuals deliberately crash the sim.

 

I my experience entertainment sim owners are rarely savvy enough to use bare sims for performances, most appear to be inordinately complex, which as you both note is just asking for trouble!

[Kristin Burner]

mewp :matte-motes-bashful-cute:

 

I suggest you read this before commenting about scripts: http://analutetia.com/anatomy-of-lag/

 

 

[Perrie Juran]

---

Ayesha Askham wrote:

Drake

Your solution is in its concept simple but the application, or getting the solution applied is far less simple. Most avas are the products of ignorantly elaborate work by their RL owners, and suggestions that they simplify them simply meets with blank refusal to cooperate.

Cincia

In 2010 use of flexi did not seem to cause a significant issue.  You are correct in that sims rarely crash now, even though large numbers of avatars are on them, though it DOES still occur, especially if, as seems all too common, certain maleficent individuals deliberately crash the sim.

 

I my experience entertainment sim owners are rarely savvy enough to use bare sims for performances, most appear to be inordinately complex, which as you both note is just asking for trouble!

---

This just got me to thinking.  In RL we adjust to the driving conditions.  When it rains or snows we slow down.  Especially on snow I will drop into a lower gear.  It's good driving habits.

But some how people don't want to adjust when they are in SL.  If I know I am going to a busy SIM I lower my graphics setting.  I turn down my draw distance.  So I can get there safely and enjoy it.

Why do people think computing power is infinite when it is not?

[Qie Niangao]

Oh golly. Bless Gwyneth, but her old blog post about lag has confused and misled so many people, I do really wish it would vanish from the web so folks would quit posting links to the dusty ol' thing.

That said, if the intended point was that most folks who talk of scripts as a source of lag in fact have no idea what they're talking about, I couldn't agree more. Although it's certainly possible to lag a sim to death with scripts, these days it is only very, very rarely scripts that account for much of any specific instance of lag.

Anyway, I meant to post on this thread because there actually are measures being taken that will help venue owners deal with client-side lag by booting over-dressed avatars from their sim. Perhaps the best place to read about that work, for now, is a talk page for the wiki's llGetObjectDetails() documentation. Scroll to the bottom and focus particularly on OBJECT_RENDER_WEIGHT, which I've just tested and does indeed approximate the metric shown in Advanced / Performance Tools / "Show Draw Weight for Avatars" (although for now, mine may possibly be the only viewer supplying info to that metric in the InfoHub sims where I tested).

Oh, yeah: this would be a good time to rev-up the drama machines ("OMG! How can I wear my hundred-sculpt boots from 2008? It's Teh Death of Second Life again!"). Because it's so much more fun to b!tch than to imagine the Lab might be doing something to address the problem. I mean, God forbid.

[WolfBaginski Bearsfoot]

I do see some bad design. And it's not something that is obvious to users and prospective purchasers.

I'm thinking here of textures. You have to get very close to an AV before the pixels in a 512-square texture are bigger than the pixels on your screen, but designers will use 1024-square textures.

Done right, on a mesh object a single 1024-square can replace several 512-squares.

There's not much you can do about this. There is information available in the advanced and developer menu options, but the Permissions system stops you from making a lower-res texture and using it in place of the original.

Why is this important? Because the graphics system uses a block of the video RAM to cache textures. And a 1024-square uses four times as much RAM as a 512-square. Using the same small texture on several different components is good: it only has to be stored once. But the caching is storing texture data for everything you can see, and at a busy event you can see a lot of AVs.

If a supplier made a "light" version of an outfit or skin, with lower texture resolution it would be a nice option to have. But until Merchants make a point of advertising the load their products have, there's nothing much we can do. Not without hunting down a copybot viewer, risking the security of our accounts (there are ugly rumours about some copybot viewers), and breaking the TOS.

A secondary factor in this is heavy use of the textures in the scenery. It's hard to measure, but I know clubs which have something more than a problem with the number of AVs present.

I am not looking forward to Christmas. There will be crowded parties, and some of them will be hell for lag. But at least they won't be swamped by the zombies.

 

[Drake1 Nightfire]

Shouldn't SSA have taken care of the skin and system clothing lag issue?

[Perrie Juran]

---

Qie Niangao wrote:

Oh golly. Bless Gwyneth, but her old blog post about lag has confused and misled so many people, I do really wish it would vanish from the web so folks would quit posting links to the dusty ol' thing.

That said, if the intended point was that most folks who talk of scripts as a source of lag in fact have no idea what they're talking about, I couldn't agree more. Although it's certainly

possible

to lag a sim to death with scripts, these days it is only very,

very

rarely scripts that account for much of any specific instance of lag.

Anyway, I meant to post on this thread because there actually are measures being taken that will help venue owners deal with client-side lag by booting over-dressed avatars from their sim. Perhaps the best place to read about that work, for now, is

a talk page for the wiki's llGetObjectDetails() documentation

. Scroll to the bottom and focus particularly on 

OBJECT_RENDER_WEIGHT, which I've just tested and does indeed approximate the metric shown in Advanced / Performance Tools / "Show Draw Weight for Avatars" (although for now, mine may possibly be the only viewer supplying info to that metric in the InfoHub sims where I tested).

Oh, yeah: this would be a good time to rev-up the drama machines ("OMG! How can I wear my hundred-sculpt boots from 2008? It's

Teh Death of Second Life

again!"). Because it's so much more fun to b!tch than to imagine

 the Lab might be doing something to address the problem. I mean, God forbid.

---

So Linden Lab Wants Us All To Be Naked?

The problem will be deciding how much is too much.

I did recently suggest that a field to enter the render weight for clothes would be a nice addition to the Market Place.  Just like I won't buy an object if the prim count/land impact is too big for my parcel, I might not buy a wearable if I knew it's render weight was ridiculous.

 

eta:fixed link

 

[dd Temin]

Qie,

Gwyneth's old post/blog  actually  had a lot of useful information if only she had left out the ARC  nazi rants and the  Jewish family dinner stories it would have been even better

general comment:

Also wanted to mention that the idea that excessive or poorly  written scripts dont cause lag is relative to what your activity in SL happens to be. 

(i.e.  the idea that  scripts only slow down  script execution and dont actually cause lag is what i am refering too)

If your activity is racing cars or doing air to air combat  for example....the slowing down of script execution is going to be perceived as  lag.

 

[Qie Niangao]

---

If your activity is racing cars or doing air to air combat  for example....the slowing down of script execution is going to be perceived as  lag.

 

---

That's certainly true, and moreover, those particular cases are good examples of a class of scripts that often slow down everything else, too. That's especially true of physical vehicles (although incredibly less so than it was in the dark days of Havok 1), but NPVs and even some KFM-based contraptions often have server-side lag effects far beyond that of scripts that manipulate data instead of objects.

The keyframed motion case is also notable as a particularly pure example of network lag that has nothing to do with image downloads. That's because KFM causes the sim to pump a steady stream of update traffic to every viewer in sight of the object, even if the motion script is removed from the object. 

So yeah, there are lots of ways for a sim to lag, but still there are many music venues that are sitting on Spare Time despite hosting dozens of avatars. Often the experience is laggy despite all that Spare Time -- and in those cases it's obvious that it's not beefier sim hardware that's needed, but rather an avatar population that puts less demand on network and viewers.

[dd Temin]

Hi again Qie,

Thanks for your information...as I was not aware of  network issues with KFM.  Can you elaborate a bit  on those effects please?    Also you mentioned  removing the KFM script  did not stop the object from continuing to  take network time  or at least that was my  understanding of what you wrote.  Help me understand that  if you have time. Thanks

The reason i was asking is  I have a submarine target that uses KFM  when it gets hit with a bullet or torpedo  which turns on the KFM  to dive the submarine  and later re-surfacein a new location.   Then the KFM is stopped until the next time the submarine is hit.  Are you saying that  there is network time being used  even when this  submarine object is not actually  doing KFM?   Thanks for any thoughts you have on this....

[Qie Niangao]

Ah, I hope I didn't give the impression that KFM was uniquely evil in generating object updates; it's not. It's just that it continues to generate those updates for as long as the motion continues. That's the same as most scripted object motion, but in contrast to llTargetOmega() rotation, which is "set and forget" as far as the sim-to-viewer communications are concerned.

KFM is also interesting because the last llSetKeyframedMotion() call stays in effect even if the script is removed from the object. That makes it somewhat similar to a "prim parameter" such as llTargetOmega(), but it works differently because the sim must keep sending those updates. I also vaguely recall there being something funky in the details of how that works, such that it's not entirely practical to remove KFM scripts as a matter of course, but I can't remember the specifics. Maybe something is dropped with the sim is restarted; I just don't recall now.

Anyway, to see the updates I'm talking about, turn on Develop / Show Info / "Show Updates to Objects" (shortcut Ctrl-Alt-Shift-U) and watch the little blue squares stream skyward. This is worth doing in any sim that's feeling laggy despite having Spare Time in the simulation frame, because KFM is absolutely not the main culprit here. Such updates are of particular interest to those with limited bandwidth or tight volume caps, as with wireless internet connections. Folks with that sort of internet connection would be well advised to check those updates when selecting breedables, for example.

[dd Temin]

Qie,

Thanks for taking time to explain

Yes  "Breedables"  can use up server resources  especially if poorly scripted.  Residents put rhese cutesy  things out that have  scripts/physics  running 24/7 eating up  sim server resources while the  owner may only visit the sim  once a week or once a month.