Initial Misc 1.7 Findings

I appreciate you going to all that trouble. One question is left regarding these findings: are the simstate results accurate?

If the simstate system itself is buggy and the "active scripts" stat is taken from that simstate-- we would have erroneous readings. Even if not taken from the simstate, if the algorythms for both systems contain the same error, we would have problems as well.

I know that's a lot of ifs. That's how I've found a lot of system bugs on computers I've evaluated... if the data doesn't seem reasonable, look for things skewing the data.

There is no way to tell at this point, since sim owners have no tools to examine script usage/ownership/placement on a sim. As mentioned in several threads in these forums, we are seriously in need of comprehensive script-list/locator tools. We can tell who owns how many prims, but not who owns how many scripts, where they are located, how much each script takes up in resources, etc. Without such tools, even if we know there are too many scripts on a sim... what can we do about it?

We need script locator/indentifier tools. As a sim owner, we need to be able to call up a comprehensive, printable list of every script that appears in a parcel of land. That list should be sorted by script owner so that we can determine who is using excessive scripting.

Bottom line is: we need user-accessible, more powerful script-analysis tools, with ALL the data, bells and whistles (ie, not some half-baked tool that will leave us with more head scratching). We need script name, owner name, object name in which the script is located, script location and resource requirements. Those 5 pieces of data, sortable by both script owner and script location, would give us what we really need to keep our sims clean.


It's just the simple matter that no matter what the current stats say, it's very difficult for me to believe we have 42 scripts per 1024m of land on our sim. I'm not saying it's outside the realm of possiblity-- just outside the realm of believeability. Many sim owners (and even LL folks) have expressed the same misgivings. Until we have the proper tools to help us measure such things and establish the matter one way or the other, I have to view that stat box reading as unreliable.

Now if we are given such tools and find that this reading is indeed true-- then we can do something about culling scripts. Until then however-- to me it's just another questionable figure (although Lee, I'll admit that you have done as much as seems possible at this time to check into the matter with the current state of tools available to you. We appreciate the effort).

In a related manner: how many times have I seen that some unauthorized user has 189 prims on a piece of land-- and can't find it anywhere. Would be nice to be able to get an x,y,z location on such objects.


But as for the current script findings... it's the old "data points to the moon being made of green cheese". No matter how many computers tell me that, not gonna believe it until a sample is sitting in NASA archives-- and even then, I'd question if some tech had been smoking more than cheese.

Hi Way I am not sure what this thread is all about but 100 prims on a person? Yikes! 5 prims is my personal maximum, or maybe 10 for a big event, so maybe people should think a little about others before they load themselves up.

If I say any more I will be flamed to death.

I'd like to highlight, in strong agreement, a few things Wayfinder said. Thing is, this is stuff that'd be useful on the mainland as well. (If not moreso):

It'd also be nice to have an "avatar script/prim detector" device ... that would measure avatars as they enter a sim. If an avatar is carrying more than a sim-owner defined number of prims and/or scripts-- it will not allow the avatar into the <parcel>. That might encourage users to drop the excessive bling and gadgets and get down to reasonable avatar design. I know we'd probably set our sims to 100 prims per avatar and 10 scripts maximum. Either that... or it would be nice to have a "shut down avatar scripts" option so that AO devices, guns and other avatar attachments could be depowered at <parcel> owner preference.

As mentioned in several threads in these forums, we are seriously in need of comprehensive script-list/locator tools. We can tell who owns how many prims, but not who owns how many scripts, where they are located, how much each script takes up in resources, etc. Without such tools, even if we know there are too many scripts on a sim... what can we do about it?

Note: Giving us LSL function calls to do this ourselves would be to say the least, cool.

I agree to a certain extent that private island owners need these tools, but not on the mainland. I can just imagine the little militia flying around sims complaining and bullying parcel owners. Frankly my advice is stop this complaining and live with it. If you can't move in a sim move yourself or leave SL. I'm guilty myself of this problem, and the problem I'm talking about is a lack of tolerance. If someone is causing you trouble on your own land you can ask them to leave or remove them, but to dissallow scripts and attachments anywhere simply because they slow your client down ? imho that is as selfish as the people who wear them.



[edit]
just in case it seems so, this is not an attack on Travis, I'm just quoting from his comment to hilite my point and answer his question about what we can do about it.

[edit 2]
I want to edit my comment to say that the suggested tools would be ok on the mainland imho if they only worked on an owners parcel. A landowner has the right to allow entry or remove anyone they desire. Clubs have long banned "excessive" attachments. But I do not support to giving tools that would provide a means of determining what is what anywhere in a mainland sim.

Lee, the real issue here isn't the changed reporting. That's annoying because it is preventing us from making measurements we can relate in any meaningful way to previous experience.

The real issue is that after a major update many of us, and I'm one, are experiencing major performance loss. Not just in this sim or that sim, but everywhere in SL.
Most of us tend to 'measure' our performance on the basis of our 'home' sim.
Because we are familiar with it's performance and we generally know a fair bit about what's going on, regarding builds, scripts, etc there.

In my case I can reference to a complete sim in which no changes have been made since the update - I know this because I own it. And my performance hit IS around 50%.

No 'From my understanding of...', 'As I understand it...', or other backout clauses - In a sim I completely control my performance is aproximately 50% of what it was pre update.

By performance loss I refer to both my personal fps - and the fact that movement is slow and jerky with frequent 'walking in a vat of molasses' episodes.

Now all the talking in the world isn't going to alter that. There is a problem (more likely several) that needs fixing. We are waiting.

And the weird thing is that, on the the other hand, many of us are experiencing a huge increase in performance. I've got less lag in my sim and significantly faster FPS on my client. Apart from a major issue with the cache causing crashes this update is great.
I'm wondering if there's some threshold beyond which the new script throttling is causing a problem in some sims.

Well we can all wonder. Some of us can try and understand it. However without tools to measure what's actually happening there is very little any of us can do.

The Lindens on the other hand should be 'encouraging' the developers, by every means at their disposal, to sort the issue out and quickly. I wonder how many newbies are bothering to come back after a few days of this?

Same here Laukosargas. I think both you and I run fully loaded big Mac's. With 1.7.1, I have experienced a sigfiicant increase in performance. Still getting the occassional 'cache crash', but hoping LL is working on it. Chatted with our well known and helpful Mac user Linden yesterday. Things will get better.

Many sims still have problems - but that is on LL's side of the equation. The client's, both Windoze and Macintosh, are definitely imporoving with each patch and update.

That's what we're discussing, is landowners having the ability to detect such on their own land.

However, as a side note... everyone in society has an obligation to that society to do their part to keep things going well. It doesn't do me any good to track scripts on my parcel if my "neighbor" is a script hog with no consideration for anyone else.

I know on Eaton... for a long time the whole sim lagged like a fiend and no one could figure out why. Come to find out, one single landowner there with 2048 of land had over SIX HUNDRED scripts on his land... and was lagging the rest of the sim as a result.

Some accountability is needed. I would hate to have LL mandatorily limit script count, because they'd probably go to an excess and nothing would work. But it would be nice to have SOME means of detecting who/where/what is causing a sim to lag. After all, every landowner is paying to keep a sim functional and just moving over and over to another sim as script-hogs come in isn't really an answer. Not only can it be expensive, it's time-consuming, irritating, and no 2 pieces of land are identical. Maybe a person likes the piece of land theyre on and don't want to move. Should they have to just because a selfish neighbor is running so many scripts that no one can move?

Then too, one reason such tools are needed is because often newbies own land and don't have any knowledge of how the system works. They put all kinds of "pretties" on their land... having no idea what such is doing to the neighbors around them.

Myself, as private sim owners we'd just love to have such tools on our sims.

This describes exactly what we are experiencing on our three private sims. Walking a long... then molasses... then fine... then molasses. Wasn't doing this before. Obviously server/software issues. LL has announced they're having imaging problems. I imagine it will take a few days to get the bugs worked out. But yup... for sure they are there, and it's not client side... 'cause like you said, we've changed nothing.

Well, one thing to realize is that when the entire sim went down from the griefing that occurred just about the same time 1.7 was released... servers got all switched around. So it could be that your land got switched to a server that is better for your layout.

But I've noticed issues all over the grid.. and so have many others. Something is up for sure. LL has announced that there is an image/texture control problem that's affecting SL grid-wide. I can accept that. They admitted it, asked for patience, no problem. Bugs were to be expected and LL will need time to fix them. As long as they're admitting the problem exists and are working on it... I can give 'em a bit to iron things out.

That's a good point Doc. It's only to the advantage of LL that they give us EVERY TOOL POSSIBLE to make SL run well. The more tools we have at our disposal, the more we can eliminate "lag hogs"... the better for Linden Lab.

GIMME THE TOOLS!

Ah, that could explain things. If you and Lauk are running Macs and the problem is with the PC interface... that would explain why Lauk is having improved results and PC users aren't. Might be that Mac never was running real well and those problems have been fixed... but PCs are experiencing the grid-bugs.

I did find it interesting-- and even funny-- that (from what I understand) SL is run on Linux-based servers... but Linux users can't use SL. LOL. There's a paradox for ya.

fyi, most of my PC using friends seem to be experiencing the same increase in performance as me. I don't think this is purely a Mac thing, although the Mac client certainly seems to be improved from 1.6. There is an issue with texture serving atm, I saw a comment from a Linden somewhere about them working on that one.




indeed!




Then more education is needed not more regulations. Newbies will do this, I was one once so were you and so were all the expert scripters in SL. We all started with a 512 plot unless we had more money than sense. We all made mistakes.

As the servers and compression protocols get better then so will the lag, I'm totally against any form of script taxing, script throttling etc. Like I said if it affects you badly you have 2 main choices, move yourself or leave. If the problem is on land you own then boot the offending scripts, reduce the number of prims, lower your usage of alpha'd textures and hey presto your lag will plummet.

Also I really don't understand what the fuss is really about, there has never been a lag free SL, not since I joined a year ago. What I do notice is that whenever there are 3000+ people online that is when everything gets really slow. Wasn't 3000 the required number in the first lagathon ?
Significant or coincidence ?

OK I'm eating my words ! I just spent an hour or so flying around and found some really weird goings on. Generally it looks like the telehub sims are totally screwed with time dilation down to 0.2 in a few I visited. All taken up by agent and images time. In other sims one sim can be lag free with 10 people and others can be borked with 1 person, script time and performance seems fairly meaningless to me. so it seems we're really lucky in my relatively lag free home sim where I think I'll stay for a while !

Hmmm, here's an interesting one...

I visited a sim that contains one store. Everytime an AV goes into the store and clicks on a vendor to show the next/prev item the sim virtually stops for a few secends...

Huge images loading? You tell me?

LOL. Yeah, the Lindens announced they're having some server-side issues, especially in texture rendering and in time dilation. They're off this weekend of course, so I doubt we'll see anything running decently until the end of this week at the earliest. But hey... I can live with that. Bugs and problems come with the territory. So long as they're being straight with us, I can give 'em a break (well, taking it for granted of course, that those bugs will be fixed within reasonable time. LOL). But I'm reasonable comfortable they'll get on top of this and correct it with all priority.

The one thing I do disagree with at this time is the suspect "22ms" general sim reading that's being touted. I haven't been on a standard sim that's met the 22ms figure yet. All 3 of our sims are configured differently, and regularly run up and down between 22.3ms and 25/26 or so. Even ElvenGlen, our most complex sim, often gets down to 22.3. So I think that stated "22ms" figure could bear some further scrutiny and adjusting. I'll look foward to see what the figure hits once the imaging and TD gets ironed out.

Well, one thing I REALLY like about 1.7....

If your back is to a wall... it no longer blocks your vision. Instead, the camera moves forward so your vision of the area still remains. That is SO nice... because I got tired of having my view totally blocked just because I'd pass too close to a wall behind me. So that is at least one major improvement.

yeah this is a BIG improvement.

Sorry - just caught this thread again.

I didn't take it as an attack at all, Larkos You're just respectfully disagreeing with me a bit

Even if we had those tools on just a parcel level on the mainland, I think it still would be a huge help. Although if they were limited to just our own parcels, I'd prefer we had some sort of script-resource limitations based upon parcel size.

That would prevent someone with only a 16m plot in a sim offloading all their work there and running 800 scripts. If sim resources were throttled based upon how much of the sim you owned, no one would have any reason to investigate anyone other than themselves. At the very least, it would help *me* be more responsible with my own scripts. And throttling would provide everyone else with an incentive as well.

Currently, there is little incentive to the average SL'er to use responsible scripts, and I think that's a problem.

Woot Travis for this latest vote... users.. please rock this vote... which gives land owners greater control over their lands!

http://secondlife.com/vote/index.php?get_id=244