Temp rezzers revisited

I stopped selling my temp rezzer some weeks ago, because too many people have difficulty in following straight forward instructions, and I decided that is wasn't worth the time I used to take talking them through it. That's just a bit of info.

Now I'm finding a problem that hadn't really been isolated in previous discussions about temp rezzers.

First the background...
I've been using 2 dozen or more temp rezzers in a sim for probably 6 months, and they rarely blinked. A couple of weeks ago, I moved my store into the same sim, together with all of its objects. There are still almost 4000 unused prims for the sim, so the 15000 limit is a long way away.

Now the problem...
In the last couple of weeks, I've had tenants in the same sim tell be that their furniture keeps going missing. It's temp rezzed furniture, and the problems started around the time when I added my whole store to the sim. That's too big a coincidence.

My thoughts...
What I'm thinking is that, in the normal operations of a sim server, the rezzing of objects is given a low priority, and other things are given higher priorities. It had been a quiet sim until I moved the store into it, and the temp rezzed objects were very stable. Now that people arrive in the store, where there are a lot objects and textures for them download, I'm thinking that that's given a higher priority than the rezzing of objects, and hence the rezzing is delayed, causing the temp rezzed objects to blink a lot, and even fail to rezz at times.

Does anyone have any knowledge about that - priorites in sim operations?

I don't see it as a problem with temp rezzers - I see it as more a problem with any kind of rezzing.

According to http://www.lslwiki.net/lslwiki/wakka.php?wakka=TemporaryOnRez

"Temp-on-rez prim limits
According to Andrew Linden, as of SL 1.11, there is a limit on the number of temp-on-rez prims allowed on a parcel based on the parcel's prim limit.

The formula is currently "temp_prim_limit = 0.5 * regular_prim_limit + 20", or 500 temp-on-rez prims, whichever is smaller. Any rezzing above this limit will cause older temp-on-rez objects to immediately be garbage collected until the limit is reached again. As the aforementioned forum thread indicates, the limit may be tweaked in later versions."

The parcel limit is not the same as sim limit. If you the parcel goes over limit things start getting sent back. The priorty is a not a simple older objects sent back first. You can avoid having objects sent back by using the 'locked' checkbox.
The Lindens keep messing with anti-grey goo settings that may have effected the rezzer.

Thank you for the thoughts, but it's not the parcel's temp prim limit formula that's causing it. I know about that. Some of the problems are in the same sim but on a completely seperate parcel, and the temp objects had been very stable there until a couple of weeks ago, when I moved the store into the sim.

On the other hand, I wonder if a "parcel" consists of all of a person's parcels in the same sim, for the purposes of calculating how many temp prims to allow on a parcel. I doubt it, but I wonder if that might be it.

I wouldn't make that assumption, considering how normal prim limits are combined among parcels owned by the same owner in the same sim.

But keep in mind that temp rez behavior has changed several times in the past, and it's usually only been described after people started reporting issues with it. I'm with the other folks who think your parcel/sim temp-on-rez limits got maxxed when you moved your store in.

temp objects seem to not show up when the owner of the object is not in teh same sim.

i got around that 'bug' by deeding my object to group.



its allways amazes me how the average user seems to have an iq below 80 on this game no matter how simple you make things you will get idiots IM'ing you 'you ripped me off this dress is just a box on my head' lulz

LMAO!!!

Was that a typo? Did you mean that you *would* make that assumption? I.e. assume that temp prims are combined like normal prims are?

No typo. You said you doubted that multiple parcels on the same sim factored into the temp prim allotment and I challenged that assertion. However I think there are sim limits on top of whatever parcel limits there might be.

It seems to be pretty clearly related to your simulator privilege usage. Are you near your max for the sim?

I hate temp rezzers for furniture. It's just cheating on the prim limit. Learn to live within your means!

I understand it now, Wildefire (it was a doubt - not an assertion )

Right now I'm trying to find out if parcel temp prim allowances add together and can be used on just one of the parcels, like normal prims do, but I don't think the help at the other end knows the answer. If they do add together, then I'd agree that the problem is most likely down to the total allowance. If they don't, then it must be something else, because there are problems in a totally different parcel to the one where the store is. At the moment, I'm favouring the former, as you are.

Wouldn't surprise me if this was emergent behaviour of strained server resources.

Servers are the ultimate multithreaded monster.

You'll have 3000-5000 scripts running all at once, and all the housekeeping involved to keep track of that - even if the script is doing nothing.

So, now enters the extended demand on resources. Even in the best multithread environment, each task often has to draw off the same limited resources - and that's not limited to cpu cycles. Suddenly your texture cache is a lot deeper, there is a lot more to rez, there is a lot more to be checked for collision.

* * * * *

The above is all speculation; I freely admit I don't have the brass tacks when it comes to task priorities and failure modes at boundary conditions.

But from a couple decades in the embedded systems design business, it would surprise me if anyone actually *did* know to high detail... though I'm sure they would have a pretty good idea of the framework.

Unlike most systems, the 'balance' of server usage on the grid is done by a sort of vague but nonpassive community consensus. Most servers run somewhere between "there's not enough stuff out" and "my god it's laggy here."

Well, the other end of the help line finally stated, "If the two parcels have the same owner then yes. Just like any other parcels prim sharing rules" but, to be honest, judging by the rest of the conversation, I don't think he actually knows. I think it's just a best guess.

Hmmm. I'm also assuming that each temp-rezzed copy of an item (including, for example, scripts inside a poseball that's part of a piece of temp-rezzed furniture) is a new asset, and hence gets a new UUID and creates a new entry in the asset server database. So if you're looking for additional strain on a server...

Just a quick correction on that. That was the old formula that was replace by (in my words):-

prim allowance - used prims + ((used prims * 0.5) + 400)

or

prim allowance - used prims + 1000

whichever is the lower number.

Is the mystery solved if the temp-on-rez limit is indeed pooled across all parcels belonging to the same owner? (I would expect that to be the behavior, only because it would have been yet more special case code to write and maintain to enforce a limit based on parcel-only count for temp-on-rez.)

If that still wouldn't account for it, I wonder if there might be a sim-wide "limit"--either intentional or an effect of how rezzing is done. That is, maybe there's only so much rezzing a sim can do in a minute before hitting a bottleneck--perhaps a throttle on comms to the asset server, or to neighboring sims, or god knows what. Rezzing involves a bit of processing by a bunch of servers, and you just might be exploring new territory with the volume of rezzing you're trying to do each minute in that particular sim.

Also, I wonder how hard the sim has to work to figure out whether a primary or child agent has to get an update when a prim is rezzed. If there's a limit on how much of a frame can be devoted to that kind of processing, then the ability to rez would also be a function of how many agents are in a sim and its neighbors.

two dozen temp rezzers?
please go die.
ta.

*points up*
There's your answer.

Or to put it more basic; The more stuff in a sim, the higher the Net Time gets. The higher the Net Time, the higher the chance of a "skip" in script timers (which are used in re-rezzing items). This puts the rezzing of temp items "off kilter" with the de-rezzing of the item. If things get bad enough, then other things start to fail.

It's not based on priority, in so much as the temp rezzing is a viable aspect. Other scripts are affected as well, but most we humans can not see.

This was why, in our previous discussions, I said to watch the sim Times, as well as Time Dialation and FPS (client and sim) over an extended period of time if one intends to use any temp-rezzers.

~Jessy

Do you have any particular preference as to the method I use, Nina?

It hasn't been solved by me, unfortunately, and yesterday's helper didn't answer the question for long enough, but said other things instead. It was only after I asked it again that he gave an actual answer, and the whole thing was so unconvincing that I feel it was a best guess rather than actual knowledge. I don't think coding for individual parcels would be a problem. In fact I think it would be simpler to write for individual parcels. Temp objects are already a special case when they are rezzed, as the existance of each one is timed. Adding code to take account of the possibility of more owned parcels in the sim could make it more complex, but it depends on how that particular part of the programme is written.

For me, those 2 paragraphs are related, as they are both about sim workload, which was my first thought as I wrote in the first post.

I don't think I'm going to get to the bottom of it on this occasion, because there are too many changing variables in the current situation. But it should be testable easily enough.

wow!
you know that you lag the sim everytime you (temp) rez something? not very nice to use 24 of them in one shop. (means 24 lags per minute). glad i dont live in the same sim -.-

Walking in a sim affects the sim, Yuriko, and you've no reason to suppose that the temp rezzers caused any probems for anyone, so your comment was completely unfounded. Everything that happens in (and around) a sim has an effect on the sim's server, but it doesn't come under the heading of 'lag' until it actually slows something down. You obviously don't understand the situation so I'll explain it for you.

First, there are no temp rezzers in the shop. A cursory read of the opening post in this thread would have told you that.

The couple of dozen temp rezzers that I was/am using in the sim, I'd been using there for around 6 months, and the shop was in a different sim. They were/are used in skyboxes, where people live, and they didn't didn't lag anything for anyone. They were very stable, and affected nothing noticeable. It's only since I moved the store into the sim that things have started happening, and it's the temp rezzers themselves that are affected - nothing else.

So, no - every time something is rezzed, whether temp or normal, a sim in NOT lagged. It is affected, of course, because it has to actually perform the tasks involved, but it is only lagged when something forces something to be slowed down, and rezzing objects doesn't inherantly do that. On the other hand, running an event in a club lags sims when a fair number of people attend it, so why not pick on that activity instead - it's a far more realistic thing to pick on

Its Valentine's day and "Phil Loves His Rezzers"

LOL. Now if only I could get something else to rez on demand, and without any lag

Here is the wiki link...

http://www.lslwiki.net/lslwiki/wakka.php?wakka=TemporaryOnRez