Prim limits is just part of the issue - should we have more limits?

Following the last Town Hall meeting with Cory Linden, listened in Lindenville (hosted by Pathfinder Linden) with several Lindens present, there was a significant amount of discussion among "other limitations" beyond prim limits in order to keep resources better under check.

To be honest, this was Prokofy Neva's suggestion, and since a quick search on the forums did not show up any discussions related to this subject, I thought it would be an idea to set up a poll on this. My apologies if this has already been discussed on other threads or even forums - with a few hundred thousand posts around, and not good enough search facilities, it's sometimes hard to find out where exactly things are being discussed.

So, to the point. The value of things is set by the access to limited resources - that's basic economy for you. In SL, this means, for now, prims. For the sake of argument, let's equate prims with "disk space" like on Web hosting services. If you need more prims (more "disk space" you are using more resources and thus you should pay more. Thus, more land = more prims = higher tier fees. That's clear as water

However, Web hosting companies have found out that "disk space" is not the only way to consume resources - bandwidth, for instance, is something that is often much more important than disk space (because the cost of disk space is infinitesimal when compared to the cost of bandwidth). So, Web hosting companies prefer to charge for bandwidth instead of Web space. It makes much more sense.

For the common user, disk space is more "logic" because it's under your control. You can decide to add or remove more things to the available disk space, and pay only what you want to have available. Bandwidth is a tricky problem, since it's not under your control (it depends on how many people are interested in your content and download your stuff). So Web hosting companies usually do a trade-off - they give more disk space to users needing more bandwidth, and vice-versa. Ultimately, "disk space" became a metaphor, an abstract concept that embodies something that the users can understand, although it doesn't really reflect the costs of the company. Balancing those two trends (how to charge for disk space when your costs are linked to bandwidth) is what makes a company be competitive and survive in the hard market of downfalling Web hosting prices.

Enter SL. Here, we have the "prim" as that abstract concept which is easy to grasp. One sim has 15,000 prims. Thus, it can have a maximum of X polygons (sorry, I cannot do the maths for you - you'll need a professional 3D designer to figure it out for you), which can have up to Y textures, which need Z MBytes of hard disk space, and ? bandwidth to upload them all to the maximum of 40 avatars that the sim can hold at any moment. If you take a moment to think about it, it's much more precise than the "Web space" metaphor on Web hosting - a "prim" is much easier to "relate" to RL costs, and it also makes a lot of sense from the perspective of the consumers (residents).

However, sadly enough, Linden Lab has forgotten to take something in account: scripts, which consume CPU power. At the moment, there is no limit on the number of scripts that can run on a single sim, and the theoretic limit, assuming that each needs 16 KB to run, is hard to compute. The problem is, scripts are very different and highly dynamic in nature. We're talking about all sort of lag effects caused due to bad scripting. This has been discussed on uncountable threads and everybody is familiar to the concept.

Prokofy suggested that LL should charge for script usage. While this is a bit too drastic - oldbies still talk about the days when they had to pay for rezzing prims - an alternative also exists: limit the number of scripts per parcel. This is a simplistic approach.

Imagine that for each 512 block you would be able to have just 10 scripts running. This would mean that you'd have to chose your items very carefully when furnishing your plot, or else you'd end up without the nice, laggy items that everybody loves to have at their own homes

This would, of course, ruin malls and casinos almost completely - by far the most laggy zones in SL. And most in-world games would also utterly fail, since they depend on dozens or even hundreds of running scripts to be fun. LL's response to this has been introducing the Mono platform, which, according to some developers, will increase a hundredfold the abilty of running scripts. Add to this the better implementation of Havok2, and the net result is that CPU usage will be "negligible".

Of course, I disagree with this simplistic view. One bad script is enough to ruin a sim - as several of us know so well - and even if running script is hundred times faster, this will only encourage people to run hundred times more scripts than usual, just because they can. After all, if this very precious resource - CPU power - remains unchecked, people will use and abuse it. Ever.

A better system would be to assign "CPU usage" per plot, and limit scripts accordingly. Yes, I know this isn't possible right now, but for the sake of argument, let's assume that Linden Lab has (finally) developed a tool which allows them to see how much CPU percentage a script is using. Typical sims usually have 40% CPU power assigned to running scripts, 40% for avatars and feeding the renderer with textures, etc., and 20% for running other tasks. This would mean that a "fair" usage of CPU power would be to restrict a 512 plot to an amount of about 0.3% CPU consumption or so. If you have very well written scripts, you could use any amount, as far as you don't go over the 0.3% limit.

R-fx networks seems to have a way to do this with an open source tool called Process Resource Monitor. I'm sure there are more around. So, on the technical side of things, this is possible. Again, it's more a "policy question" and not a technical one (although the technical implementation is necessarily hard, of course).

Having a sim server not running anything is silly, so I guess that a better approach would be to have people with a 512 plot a guaranteed minimum access to 0.3% CPU power, but being able to "burst" the CPU usage to higher values if there is available CPU. This would mean that you could have a big mall with lots of laggy scripts cramped in a small space - if nobody else would be using that sim (or having no scripts on their own plots).

Of course - if you need to run more scripts, you simple add more land. That's the same principle as with prims.

The first reaction to this proposal was "this will completely destroy the value of good and talented scripters" since they would be unable to do their highly interesting (and laggy!) scripts in their "backyard". To them, we gave the same reply as to the people needing thousands of prims for their artistic creations - use the sandboxes. You can test your laggy scripts there, tag them appropriately ("warning: this script usually consumes about 5% of CPU power and is really just appropriate for being run on a 8192 m2 plot", and sell them as usual - just like people do when they cannot create high-prim builds on their own tiny plots, and have to go to the sandboxes for that.

The net result for this "drastic change" is that CPU consumption, neglected so far for scripts (although not for rendering), would finally be "checked". And people would also start looking for better programmers, who are able to provide them with low-lag scripts by employing better algorithms. I mean, who does really need a teleporter script which blinks the hovertext on 30 teleport buttons every half second or so - bringing down the whole sim due to lag?

So, what is your opinion on this?

Yeah, this has been discussed a few times since the townhall but I think it's reasonable to bring it up again.

I think the key here is to focus in on what scripting commands create significant lag.

Particles, for example, can be problematic. Similarly, Temporary on Rez can create lag.
Putting some kind of throttle related to your tier onto these two commands may be the appropiate exercise.

Scripting lag is generally non-existent except for the above and a couple of other suspects. Most lag is created by lots of prims or too many avatars and their attachments (more prims).

Some extreme cases are caused by scripts out of control and listeners, but this may improve when mono comes around.

Personally, I think the solution in the extreme cases is just better detection tools. I'm sure user education will help get rid of those.

As for the particles / temporary on rez / etc .. Yes, I think connecting these to tier levels is probably the best solution.

Gwyn,

GO in "advanced search" and search under the terms "script" and "Prokofy Neva" and see all I've written on this, and all the controversy it has sparked.

Here's just one thread, "Should We Charge for Script Usage?"

/120/38/44774/1.html#post474609

I'm not swayed by arguments that avs are the biggest laggers, that "my lag" as blaze so very revealing describes it, it about prim attachments like hoochie hair.

Well, let me break it down to you, blaze. "My lag," which is different than "your lag" is about one or two individuals having more than 300 scripts on our sim. That's the long and the short of it.

Now I am well aware that Cory said they're working on it, making faster scripts, etc. but you don't have to be a brain surgeon to realize that just means more expectations in a rising tide, and more users and more scripting.

I've also well aware of what he described as tying it to slices of land, but I want to hear how that will work. Will it work as a punishment, i.e. if you attempt to use a script, it will not work, or it will slow down? Or will it work as a limit, i.e. just like on a 1024, you cann't put out that 235th prim, it just won't go, it isn't that you get a non-rezzed or half-prim, it's just an upper limit. People have talked about how this word work in terms of speediness or partial usage and that seems odd to me -- to slow down the execution of some scripts, like making a door slide slower??? My concept was just to bill above a certain level, not per script, as you do with prims, and the billing makes an upper limit that serves as a deterrent.



blaze, this is no good, just NO GOOD at all. "User education" is a draw on the Lindens and the free help, and it isn't a productive one. No amount of talking to people gets them to concentrate their minds wonderfully like a dollar amount. Have them pay to play. When they have to pay, they stop playing. Otherwise, they go wild.

And having all that listening stuff, as you well know, lags the sim worse! I have lots of tenants anxiously putting out their "Scrubbies" over sim lag when they don't realize they could just press ctr-shift-1 now in the new version and see the list of numbers including FPS. And yes, FPS is a good number to look at for a rough understanding of lag, even if we realize that it doesn't tell us everything.

Your notion of "bad scripts" just isn't large enough. Let me break it down to you:

-- bounce scripts -- pernicious all their own, and should be banned themselves for all the reasons I've described, but they are also big sim laggers, just live next to them and you'll stop theorizing about this in a jiffy
-- turntables -- in stores, or in some houses, this turning of something for viewing is
-- some scripted objects that talk to the servers or outside servers, like "I'm online" sorts of devices
--various sex balls, animations to look like swimming, eating, refrigerators' opening -- a 1001 things that people put in houses. You all don't live in the world, and don't see this.
If animated things don't eat up scripts, then I'm a monkey's uncle. They do. I see them. I count them. I do the math. I see the lag. I relate the two. Is this like calculus??? No.

Which SIM are you referring to that has '300 scripts' causing lag?

I don't like paying for scripts with cash. And a fixed number of scripts, allocated like prims, ignores the huge difference between scripts.

Since I think we can agree any solution (even paying) would need to take account of this difference, we all agree that measuring the CPU utilisation of a script, and thus a plot, is essential for progress.

Once we can do that, we are half way home. If we could also SLOW DOWN an individual script (eg. by allocating it a variable number of "time slices" perhaps) then the door is open to much better solutions than simply counting and allowing or not.

How about this ?

Every plot is allocated a certain number of target "time slices", depending on its size (like prims).

Every sim has a target sim fps which it is not intended to fall below (say 1200?). Call it the Minimum Speed Limit, MSL.

As long as the sim remains above the MSL, everyone can use as much script processing as they like, with any slowdown towards that limit shared by everyone equally.

As soon as the sim hits that limit, everyone is slowed down to bring it back up. But each landowner slows, not the same amount, but an amount depending how far he is over his share. Those more over their guaranteed share lose more timeslices.

Those within their allocation will normally not slow any more at all, unless some abnormal situation occurs, requiring a call to maintenance.

We need a rule, or algorithm to determine eaxctly how it would be done. The greediest boys should be slowed most, of course.

If E is the number of time-slices you are using in EXCESS of your allowance, I suggest :

The landowner with greatest E is slowed alone (all his scripts), until the sim comes back to MSL, or his E is reduced to the level of the next greediest.

If this is not enough, he is further slowed until his E is indeed the same as the next greediest guy in line (next highest E), then they are further slowed together until.... etc.

This may seem complicated, but, if the software has the power to measure and control, this sort of algorithm is childs play. IF, of course, and there is the difficulty.

It would be nice if we could have done something similar with prims, to stop all those lovely unused prims going to waste. But you can't deprive a prim bit by bit. Its either there or not.

There are big ifs in this proposal, and I can't judge how difficult they are. Particularly the ability to throttle back the scripts belonging to a particular landowner.

But I can see no other solution which is as good and fair as one of this type.

I hate the idea even of a fixed allocation, like prims. Its bad enough watching the prims go to waste. Don't lets have to suffer it with CPU resources, too.

I say, wait. Suffer the lag for a bit longer, work towards doing it properly. See if the speed-up changes do in fact help.

My suggestion ignores the effect of hordes of arriving avatars, and sacrifices everybodies scripts to running them. This is probably wrong, and the script speed control I advocate should be applied to hold just the script load to some desired level, depending on what else is going on.

The basic idea is just to throttle back the greedy (those using more than their "share" first, when the going gets hard. But let everybody use what they like when overall speed is ok.

No, because the server ignores the different, when it gets above 300, and especially 500, it slows down. This is a fact of life. Numbers matter.

If there are hairs to be split on kinds of scripts, sure, fix it so that only the "bad" scripts are the basis for charing.

In the previous patch, you could ctr-shift-u and see the kinds of scripts on your sim. You cuold walk around, and see some as blue, some as red. The red ones were the greater laggers.

On the one hand, Lindar has just finished saying in another thread that he hates the way developers' awards work because it means that people in clubs succeed at "their neighbours' expense", taking away their FPS and sim performance.

I couldn't agree more. And the way to address that is to make them pay to play.

You mean to tell me the lag we're all suffering from is due to turntables and sex balls??!

Before we go and make any system to regulate scripts, I think we should be looking at educating people using them and moreso, people beating the drum for charging for them.

Sex balls or other AO scripts should be set to activate on touch - so when noone is around, they aren't doing anything or using any resources. Bounce scripts are a whole other issue - as has been discussed before, yes they are annoying due to the effect they have on your AV, but do they produce a bunch of lag? We would need to turn to a knowledgeable scripter to find out.

I'm not for charging for script usage until we have a clear understanding of what types of scripts cause lag and ways in which those laggy scripts can be improved. On top of that, it would be a friggin nightmare of LL to calculate each script usage per parcel - as they only fair way to do it is to calculate, by script, the time and the processing use. You simply cannot apply a blanket approach to this.

Additionally, I'd like to say that I'm not in favor of charging for scripts - no more than I am for charging a surcharge if you decided to have 20 friends over to your 512 for a 4-hour party.

I so agree. We must find solutions which avoid this. I guess you think my "selective slow-down" suggestion is technically impractical ? If so you may well be right.
But would you approve in principle, Juro ?

I faer that getting ALL people voluntarily to act in the common interest is forever doomed. Have you read about the game-theory and psychological research into eagle-dove optimal strategies?

I think we should keep all options for a resolution open, including a benchmark lower-end performance point. It just seems to me that we're putting the cart infront of the horse and I would rather identify possible lag issues with scripts, educate users on how scripts really affect performance, eductate on how to write low-lag scripts, and then... and only then, start to figure out the method to reel in runaway laggy scripts.

I admire your optimism, Juro. You must be a really nice person to know. Me, I'm a bit of a pessimist, though not a defeatist. I just tend to think a healthy cynicism is more suited to forward planning.

Well... we all know that lag is a major source of frustration for almost everyone, so we should definately work toward reducing it. I know that prims cause lag, so recently, I went through all of my prefabs and found ways to cut out a prim here, a prim there. Sure, it's a small amount, but every prim helps - right?

It's the same thing with scripts. We can't point the finger at them in a blanket fashion and just slap on a surcharge and think that's going to 'fix' the problem. We must understand the problem on a technical level - that means we'll need input from the scripting community and also LL. Then, we can start talking about ways to level the playing field.

And healthy cynicism is very helpful in situations like this - which is why I don't buy into Prokofy's suggestion of a usage charge, at least not until we get our collective heads wrapped around the issue.

Well, the mere existence of a script (or a prim) lags a sim. That's a simple fact

Prims are also "more laggy" or "less laggy" according to their parameters. A complex prim, with lots of "prim torture" and weird textures (specially half-transparent ones) and bumpmaps, is way more laggy than a simple cube with a blank texture. Or "lighted" or "metallic/shiny" prims. The worse case scenario is prim hair - nothing lags the sim more than 2 or 3 avatars in it with 250-prim hair

Now Linden Lab has made a simple rule for the usage of prims in a sim. Despite the enormous difference of a 250-prim build made of simple cubes with blank textures and a single colour, and 250-prim hair (perhaps 20 times as much lag for the latter), your land can hold either type. This is to simplify accountability. I imagine that in a distant future, when a 512 plot will be able to hold a million prims easily, you'll have a different system in place, that counts prims according to their "lagginess".

However, this is not the case right now - a simple system provides us with all we need for the moment.

Can we apply the same to scripts? Eventually, yes, if we're willing to use trade-offs. A simple touch-response script does not create much lag, that's true. A very simple voice-activated sex ball lags billions of time more, especially if it has a built-in timer to rotate
the textures inside, display an accurate clock to the second, moves physical objects, and whatever else. But the point is how can we measure the "lagginess" of a script before it is actively used? Unlike a prim, where you can know its physical properties just by looking at the numbers - a simple formula should be able to correctly "predict" the lagginess of a single prim - the same script, given a different environment, will react differently.

A bouncing script which has to bounce, say, 20 avatars in a second, is far more laggy than the very same bouncing script in an empty sim.

The problem right now is how to define "lagginess" - except dynamically, looking at how much CPU it's "consuming" at every second, and trigger something to allow it to run or not.

I like the idea of "slowing down" a script if it goes over a threshold - but I don't think that the LSL virtual machine is that advanced. I imagine that the overhead in calculating that threshold is far more effort than simply make "everything run faster" (which is the current Linden approach).

So, if I understand Lindar correctly, what you suggest is that if you have 300 scripts (or any other number) running, all scripts run as fast as possible; if you have more, the person with more scripts will be the first to be "affected".

Now this is terribly unfair. First, 300 touch-activated scripts are way less laggy than 300 sensor-activated scripts. You can be on a single 512 plot with 1 sensor-activated script which is getting the whole CPU, and a poor guy with his 299 very CPU-friendly touch-activated scripts, owning the rest of the sim, will get all his scripts lagged if he adds another one (and yes, it's VERY EASY to have ONE single script to consume almost all CPU in a sim...).

So, while the number of scripts is a good indication on "lagginess", it certainly isn't the only one. A bad script will always create far more lag than dozens of well-scripted ones.
So the only fair way we have to prevent this from happening is giving each user a share of CPU power for running his/her own scripts - according to how much land they own in that sim. There is no "fairer" alternative, and it's easily accountable. If you're at the top of your alloted CPU power, your new scripts simply won't work. That's all that should happen, like when you rez in a prim over your limit.

I understand the reasoning behind "let's not waste CPU power!" since it *is* wasted on most sims nowadays. I agree that a sim without any running scripts should allow people to use more CPU power if nobody requests it. As a similar example in RL, I have a cable connection which guarantees me 2 Mbps download bandwidth. But if no one is using my segment, I can go up to 10 Mbps. Many Internet service providers reason in the same way - they guarantee a minimum level of service, but if no one is using that network segment, you're able to use more bandwidth over the alloted "guaranteed minimum". I certainly agree with that idea.

As to the misconception that "a faster scripting engine" will mean that everything will run smoother - think again. This is the same reasoning behind "in ten years, we'll have computers 60 times as faster, so we won't have to worry if Word is running slow today". Word running under Windows 2.0 was as slow as it is running it under Windows XP. Why? Because programming became sloppier and the features filled up all available memory and computing power That's an universal rule: a program will grow to the point it fills all available memory and all available CPU power. This is an universal rule, when there are no bounds, checks and limits on the usage of a resource - it certainly is not limited to the computer industry. What will happen with a 100-times-faster scripting engine is that we'll get 100 times as many scripts running on a sim, just because we can.

Harsh as it may sound, Prokofy's analysis is entirely correct. The only way to reduce scripting lag is not to improve the scripting engine, but to limit its usage by taxing it. The way we tax it is a different matter - there are really several ways to accomplish the same results. A few suggestions are here - some are difficult for LL to implement, others are unfortunately unfair. A trade-off should be found.

BTW, the voting feature for this proposal is here, if you're interested in supporting it.

By that logic, you should be taxed on the number of visitors to your parcel as well. Include that in the proposal, and I'll support it. We should then, by the same logic, tax any prim that is highly tortured, and especially torii.

No no no, Gwyneth, my suggestion was nothing to do with number of scripts at all.
I was suggesting basing the slowdown on the actual aggregate of the CPU time the scripts on the plot were using right now. Trouble is, I'm probably crying for the moon, though, aren't I? Technical feasibility-wise.

It does look like all this time slice totalling would impose such an overhead you-d be running at half speed just because of that.

Mind you, I'm not certain. Does anybody know about this stuff? Any modern operating system is already handling tons of processes at once, dishing out time slices according to some algorithm taking shifting priorities into account. With an average, say 50 landowners in a sim, if the tasks for each were categorised together and all used a priority which was dynamically assigned to him dependent on an algorithm such as I describe, you could just pull his priority down to slow him down. We'd just need to sample the utilisation, computer the algorithm, and adjust up to 50 priorities, once per half second, say?

That wouldn't be too onerous, if it was riding on the time slice allocation/priority features already in the operating system, running real fast in the very deepest loops, maybe even hand-optimised in machine code.

The problem is, our scripts aren't run directly by the operating system, I guess, but in a slow virtual machine handling its own time allocation, and very slowly. Might be passing micro-tasks to the op system, but I doubt it.

Can anybody who is up-to-speed on this help us out on the probabilities? I'm getting rusty on it now, as must be obvious to those in the know. Too much time spent managing other people lol.

Heavens above, surely exactly this problem must have been solved repeatedly by people creating multi-user systems. At least half of them must have addressed this "minimum service for all" and "throttle back the greedy" requirement? There must be readymade solutions all over the place.

Wow, Jillian, thankyou.

Who started this as a separate thread then, and why?

Never mind. I see your post at
/120/38/44774/1.html
which beautifully describes almost exactly what I am fumbling to put over. What I don't quite understand is where this description fits ?. Is this a proposal from you? Is it a description of what LL are implementing, about which you have inside information? Is it part of Mono ?

Ill wade through the rest of your thread, hoping this will be made clear, but if it isnt I might need a bit of help to the answer.

Edit: oh I see. This is a poll thread someone wanted, relating to the discussion.

I might have missed this in a post. But what is the reasoning behind not forcing the clients to execute these scripts on the client side more and less on the server side?

I am sure a rotating sign does not need to be executed on the server side, each client can execute that script locally and save the server some much need resources. I understand that some script would be required to execute on the serverside... including but not limited to teleportation, communication, and other scripts.

Interesting question, Jesse.

Just examining your example only, I suppose if its rotating quickly it wont matter if we see it in different positions (as we do particles). But if it slows down and stops, you wouldn't want the two of us to disagree about where it was, would you? So the server would have to define the true position, and tell us all. It would have to run the script. It would have to do what it does now.

Does that make sense ? I need to think....

Imagine how dramatically the landscape in SL could change if this were the case, and people lagged themselves with their rotating for-sale signs...instead of other people...but...I imagine the way it would work is that my viewing other people's stupid spinning signs would slow me down client-side...and not them being slowed down for sticking it out in the world in the first place. I think taking this script out of the library might be a good idea.

You send true position and then have client execute to that position. Also... I have yet to see a reason I would careless if that rotating img lined up between two players.

If we started down this path I just believe it will eventialy cause harm. Cutting content is the last thing I am ever in favor of. If placed on the client side with the ability of theclient to deteremine if it wishes to execute script or not would solve two problems with one stone.

SL is only 17MB big.. that is a drop in the bucket in todays market. I have sound files larger then that They have plenty of room to incorperate client side execution of scripts.

This is NOT true!!!

If I have a script in a prim that is only activated by a touch, then most of the time its not impacting the sim at all.

Or even more extreme, here's a script that makes one function call to set some hover text when reset, and then does absolutely nothing :

default
{
    state_entry()
    {
        llSetText("this script doesn't lag a sim", <1.0, 1.0, 1.0>, 1.0);
    }
}

It doesn't lag a sim.

- Ace

That's an absurd suggestion, Prokofy. As someone who admits they know little to nothing about scripting and its effects on server performance, you are one of the last people who should be making suggestions about what scripts should and should not exist. There are plenty of good uses for rotation scripts besides spinning signs. Banning a script is not the answer.

As I've said over and over - we know that there is an issue, but we need to consult with professionals on this matter. We need to find out what types of scripts use a lot of processing resources and if there are ways to code those scripts better so that you end up with the same function with less pressure on the server.

We cannot make any good and sound suggestions for fixing the problem if we don't fully understand *what* the problem is.