Animation Overrider - a source of lag?

I found the Franimation Override GPL object in Yadni's junkyard, and I decided to take a look at the code. Now, I'm totally new to scripting, only done it for a day or two, but I do have years of real-world programming experience, so I think I know what I'm doing. The animation override code seems to work by running a timer every hundredth of a second to check what animation is currently in use, look it up in a list, and start a new animation instead.

From what I understand, that basically means the script is going to use as much of the sim's time as it possibly can. This sounds like a bad idea to me. If everyone starts using this script (and it seems like a lot of people are) won't that make a rather nasty lag situation? Or am I missing something? Perhaps it's not so bad because the sim only gives the script a certain maximum timeslice?

Of course, all of this is a good argument for linden labs to give us an API for overriding animations

Heh... I don't know about the technical details, but I do know that FlipperPA Peregrine has stuff to say about this. Flip? The mic is yours

I haven't looked at the code... however, i do know Francis is a pretty well-respected scripter IW and a programmer IRL, and wouldn't think she'd intentionally create lag bombs.

I AGREE with you though!... it'd be SUPER nice to be able to have an API built on animation overrides... essentially, it would look a lot similar to the Gestures API.

Have you done any testing via debug menu at all?

I don't notice a heavy amount of lag around my place of business in Chartruese (which specifically deals with animation override clients).... but then again i haven't done any testing. Maybe i should...

--Water

Yes, I believe you've highlighted an excellent example of a script blatently wasting sim CPU resources. This pretty much assures that the timer() event will be called every time the task gets a timeslice. If the script is also making string or key comparisons, it's only bogging more.

Though it seems silly to anthropomorphize code, I'll do it: that code design is sociopathic. Even if the timer were 0.1 seconds, it'd be way too much. The only nice thing I can say about it is that at least it "goes away" when an agent derezzes. (Unlike a certain greeter script recently posted to the script library forum that used the llSensor() event on a 0.1 second event timer to IM anyone who approached!)

The sad thing is that the ongoing abuse of the timer event by folks may well force Linden Lab to set a lower threshold (above 0.01 seconds, maybe 1.0 seconds), limiting the flexibility of the system. Though there are few applications where such a short timer event interval is appropriate, there must be some (which would only be sustained briefly), and they'll be left out in the cold when the API is limited as a measure to stop abusive coding practices. Don't think it'll happen? Look at llGetNextEmail(), which now has a five-second auto-sleep.

*sigh* All it takes is a few scripts like this to offset the best coding practices of 1000 other scripts. It wouldn't be so bad if it just did that occasionally, but a full-out continuous churn is simply resource abuse, cut and dry.

LOL, that's a great line, Chromal. "My Pet Program".

BTW, I thought the version of Fran's AO code being given away at YadNi's was the Flip mod? If not, Lex, I recommend you go to the Mourning After Store in Indigo and see the the Flip mod, as it contains these comment lines:


// modded by FliperPA to cut down on lag by 1000% without cutting much performance
// also set to listen on alternate channel to stop server parsing everything wearer says in chat
// GREAT WORK FRANCIS!


and


// How fast we should poll for changed anims, changed by FlipperPA to cut lag
// Changed from 0.001 to 0.25


I do not know about the technical intricacies involved behind this, as I mentioned. Further info is indeed appreciated.

YES! It is a source of lag! BIG TIME! One time a Linden came to check the performance in Le Cadre, and he said the biggest script running was "Summer Donovan" 1 of the 5 people on the island, and mind you we had over 150 vendors and light flashing floors, and her Animation Overide Attachment was the largest resource sucker on the entire island! lol

In my experience a timers threshold is 0.1 seconds, not 0.01. setting it below 0.1 doesn't do anything. You can run anything you want inside said timer event and it'll slow the timer cycle down even farther, not take up more timeslice because functions all of thier own built in delay depending on how resource intensive they are. things like IM and llEmail have large delays because they require communication between seperate machines. other functions have delays of 0.3 or so seconds because they require loading content such as images or sounds. llSay has an 0.1 second delay arbitrarily to keep it from hitting the sim too hard. so no, a timer event set low reguardless of what's in it is not going to lag bomb a sim.

Now an Array of scripts each running timers or do loops or whatnot is very capable of lagging a sim. Sensors are worse than timers at low intervals but have a built in delay of 0.25 no matter what you set them to. Sensors will trigger every 0.1 second or so but if it hasn't been long enough since the last sensor event they simply return no_sensor to keep from hurting the sim. listens seem to increase lag in large number more than the sum of the individual listen lags. the linden scanners report the timeslice taken by an object and an avatar is counted as an object so an avatar running scripts with timers and very likely listens is going to take up more than say a single vendor, but the sum of the vendors easily over shadows the avatar.

To sum up. A single animation override script is not going to hurt a sim. but avatars do tend to wear multiple scripts that opperate on timers listens and sometimes sensors and a lot of said scripts can hurt a sim though you'd have to test on a case by case basis to prove it. Some avs are also made up of lots of prims which can hurt the sim for a short period when they first enter, but thereafter will only slow the clients down. That's not good either but don't confuse it with slowing the sim down. In fact a sim fps of 200 is almost undetectable to someone with a really good video card. The things that cause your personal framerate to drop can also cause sim lag which is why there's some confusion. Vendors for instance may not use a lot of resources for their scripts but if there are enough of them each with different textures and if the textures are switching because they're in use or on timer, the act of uploading content to several uses takes processing time. Possibly more than you'd imagine and it depends on the os and config.

Also, vehicle code even when idle and non-physical can take a chunk out of the sim processing power because when vehicle paramters have been set the sim constantly polls the object. creating an idle state in the vehicle script seems to fix this problem. Also having another script actually turn off the vehicle script should (should, you'd need to test) fix it.

Hi all,

I'm Francis Chung. I wrote the Franimation Overrider. I'm going to try and address the issues brought forward here. The short is, let's put away the pitchforks, I don't believe it makes a significant difference.

There are 3 kinds of lag. Network lag, sim lag, and client lag. This discussion focuses exclusively on sim lag.

A while ago, I posted a study in sim lag, if you'd like to learn more on the subject.
/54/c8/25865/1.html

First of all, this is not a script you're going to see very many copies of, running in a single sim. Noone will use more than 1 animation override, and since sims are limited to 30 avatars, that means we have a maximum of 30 copies of the script. In practice, I doubt we'll see that many people using animation overrides.

Second of all, LSL doesn't run fast enough to poll avatar state 100 times a second. The Franimation Overrider (FO) usually ends up polling around 5-10 times a second in a fast sim. This number of times it polls per second goes up as the sim gets faster, because it gets a larger time-slice.

Okay, let me talk about sim lag in general for a moment. If your sim has an FPS > 100 or so, it's doing fine. Your experience is not being significantly degraded.

When the sim FPS is high, who cares how many cycles your scripts are burning? Everything's working great!

When the sim FPS is low (ie. we're lagged), each script gets a smaller time-slice. The Franimation overrider polls at a much slower rate, maybe twice a second.

If I understand what Flipper's done, he's modified his copy of the FO to reduced the maximum theoretical polling rate from 100 to 4 times a second. The net effect is this:
- When the sim is not lagged, it will consume less cycles.
- When the sim is lagged, it will behave the same.

This is not beneficial behaviour. What we want is scripts that consume fewer cycles as the sim gets busier. Which is exactly what the FO does.

Hope this helps

Okay, straight from the Fran's mouth.

That was one post single lines of chat couldn't cover.


And on the flipside... here's my daily slibel:

Too many big word. Words have too much size.
I still sue you Fran
Fran AO known as FO , can F Off.. looks too pretty
Swirl color cool design
Cripple little by little
Cause all the brain damage
Avatar brain go mush gray, have to relog
More slow than laggy lag lag than all big club put together
Here is truth: FO IS GREEFER TOOL.

Hey, Francis.. I didn't realize this was your script. Uh... I'm angry at the script, not you. But I am a little disappointed.


Well, I'm not referring to lag per se. Once we're at a point where it's lag that we're worried about, it's too late. We've failed to conserve our sim's resources.


This is fair. Let's assume there's only one or two, because that's probably realistic. Even if it's only one instance of the task executing, it is excessive. Multiple instances just multiply a bad scenario and make it worse.


Right. It'll chug and either fill the event queue, or maybe the timer slows. I'm hazy on the specific details of how the time-slice availability effects a fast-event-triggering script, but, yeah, the end result is that it'll only take as many resources as are available for a task.


While I'm not going to say you're wrong, this is completely debatable. A lot of how the sim responds will depend upon why it's down at 100 FPS. A sim full of agents at 100 FPS will have more headroom than a sim that's empty or relatively quiet and at 100 FPS. World of difference, though, in terms of how world-interactive tasks will behave. In some cases, things like building objects, physics, and other behaviors will begin to really chug. Events start getting chunky, other tasks-- even ones that use the resource-intensive API calls sparingly-- start to break or, yes, lag.

A bad assumption to make is that 'available, unused' sim CPU cycles are "wasted" if not used. Nothing could be further from the truth. Those unused cycles become a sort of inertia; more frames per second, more headroom to soak up transient loads that even efficient scripts sometimes create. In all-- A better interactive experience for the users of the sim. That is the currency we are trying to preserve.


This statement is dangerous because, on the surface, it almost makes a kind of sense. The problem here is that we know that a cavalier attitude like that will make a plentiful resource scarce when it's applied to real situations. The tragedy of the commons sorta rises out of this kind of thinking, e.g. "Well, if I just do this, it won't really matter." It's no way to manage a sim, and this kind of logic applied to anything else causes problems for everyone else who has to share those resources, be they lights, particles, HAVOK time, or task time.

Getting beyond the abstract part of my objection to this attitude, let me add that you seem to be assuming each and every sim out there is some sort of fallow field of available task CPU time just waiting to be put to use. No! No, some (many, really) sims are not so healthy to begin with, some are just on old and slow hardware, others are suffering a transient agent load. You know this script is attached to an agent. Agents move though the grid routinely. Isn't it better to design with the attitude that a sim may be heavily loaded *or* it may be lightly loaded but in need of good stewardship? I'm not saying do less; I'm saying do more, but, do it responsibly and consciencously. And, especially, if you're not able to do this, don't create a loaded gun and give it to a trigger-happy noob.

I realize you still won't see "what the big deal is," but it is a big deal. It's contributing to a limitation of the potential of what the SL experience can be.


Right. The script will continue to take every last cycle it can, even as the sim slides toward deep think.


Yes, I believe that more or less sums up the behavior of Flipper's mod, if I understand what was changed correctly. A slightly different way of stating how Flipper's mod behaves would be: "the modded script uses fewer resources on a healthy sim, reducing the overall sim load as well as the chances of transforming that region into a heavily loaded morass."

The thing I find especially troubling with your reply here is that I *know* you are a very smart coder, and it's as if you're willfully wishing to make it sound as if this script consumes few cycles overall, which it absolutely fails to do. You should have said, "My script consumes so many cycles that the only way to make it use a nominal amount of sim resources is to activate it in a sim so hopelessly borked that there are not enough resources available for it to steal more than it should." That would have been accurate and directly to-the-point.

What I don't get is that good coders usually retain a certain amount of pride in creating software that does something cool while being so well-designed so as to seemingly have a hidden CPU somewhere up their sleeves for as few resources as they need. Instead of stealing cycles from thin air, your script simply steals them.

C'mon, Francis. You're respected for your cool scripts; why not lead the charge against heavy sim CPU loads? This isn't the first time something like this has happened, and I'm telling you, your scripts get at there, into random Joe User's hands, and they're used in ways that diminish SL for all of us. Stop helping the plebes shoot our feet off. Show them how to be good stewards, instead.

I also agree its a flawed idea too pool as often as you can assuming the load gets spread. You would be taking time slices away from other scripts that may actually depend on getting them. So some anim overrider that would only need say .25 sec or so would take at least two times more resources then needed and using resources other scripts could use. (I say only 2x more because .1 I beleve is the minimum). Im always for optimizing scripts, I just wish the lindens would add functions to help with it. (ie, changed event flag for anim_start anim_stop, ect). Ah well. in any case I dont think it was 100x worse like some ppl sugested though, hehe. fun times

Hi Chromal,

Most of the rest of you post is about philosophy. I won't address each of your points individually, but without reiterating what I've already said, here are a few thoughts.

Regarding philosophy, I see this a lot. People spend time optimizing things that aren't a problem. A good book to read on the subject is Michael Abrash's Graphics Programming Black Book.



It's GPL'd code. This is what I like about open-source. If you don't like something, fix it.

This is why I wrote the script in the first place - I wanted to modify an existing script, but I couldn't, so I had to write my own. You could probably even set the timer to > 10 second interval, and it will work mostly alright.



I disagree with you. It doesn't fail. It does consume few cycles. This isn't DOS. SL has built-in timeslice management. There aren't any tricks such as circumventing the time-slice management by using multiple scripts. Try to measure the amount of compute time consumed by a single script. You can't, it's that small.

You've used the word "steal" a few times, and I believe you're using an excessively strong word in this context. Everyone entitled to their fair share of compute cyles, and no single script will use a disproportionate amount.

I think for me, this discussion has come to a close, unless someone would like to share some new data?

honestly francis i find that kinda cavalier attitude problematic... you had the same response when confronted with your original tree leaf dropper (which *one of* could easily add 2ms or more time slice) and did address things with the much more economical second version which doesn't consume resources anywhere near as bad as the first.

Still. Its the exact same attitude that is the reason lusk remains to this day so loaded that even empty its mostly unusbale, when its on older hardware. What you fail to understand is you aren't just taking resources away from someone elses script... you could be taking them away from avatars moving, or people tryin to build and having things get sticky.

There is a better way to do your script, its not a big deal, ya go thank you and you endorse, and incorporate the update. *THAT* is the point of GPL code, letting other people contribute with ideas and suggestions, and incorporating them into YOUR project. Not thumbing your nose and saying 'well okay smarty pants fix it yerself' and then continuing to release the problematic version.

Its not philosophical at all. Your code is unnecessarily resource intensive. Like your first leaf tree, there is a better way to do the *same* thing...

perhaps you should be the one checking up on your reading, whats suitable for a graphics intensive application does not apply at all to a 'background' task. Its assumed a computer is running *ONE* second life. Its assumed a server is running one thousand tasks. Even if its not, program like it is, because one day it very likely *WILL* be

Whoa. Spawned a bit of a discussion here.

Thanks for coming to my aid, Chromal. You've basically outlined the points I hbad in my mind: what we're talking about is a principle, not necessarily something that you're going to be able to actively measure but nevertheless very important. One AO won't do much, given today's hardware, but if they become incredibly popular and every character uses one, I bet they'd really start to add up.

I played and adminned on MUSHes a lot, and we ran into a very similar problem. I think of SL itself as a 3d MUSH, the ideas are very similar, except MUSHes are text-based. There's a scripting system, which has its own timer system and such. I used to admin on a MUSH running on a 20mhz sparc station... we constantly policed the wait-queue to make sure people weren't running things every second, because it really put a dent in the performance of the server.

Anyway, aside from that "back in the day" rant, the fact remains: repeating something "as fast as possible" isn't cool. By definition the script's going to be taking as much as the server will give it. Sure there's a multitasking system, but it's probably not as robust as, say, the one in Linux... and I've definitely seen my linux box bog down under even one task that's misbehaving. The ideal is that every script gets a fair chance, but in reality, it's not that simple.



See, that's where things get tricky, though. In Francis' defense, I imagine he had a darned good reason for making the AO poll as quickly as possible. With a greater poll rate of, say, once a second, you could conceivably get little blips of the wrong animation. This might have an undesired effect. Since there's no convenient API for this, perhaps the AO script is not unnecessarily resource-intensive because there's no other way to achieve an acceptable result. I'll take a look at the Flip mod and see how it performs.

I think the best idea would be to find the greatest timer value that achieves a good result. That way the script isn't running "as fast as possible" so there's more time for other scripts to get in there. We can't just say that any script that puts "too much load" on the sim should be rejected, since some things just take more work than others... but taking more resources than are necessary is a bad idea.

For now, I'm skipping on the AO thing, but I really wish I could give my av a less girly walk

nah given the fastest timeslice allowed in timer events is 0.1 second settin it less jus proves someone was careless

wouldn't it be great if there was a trigger for animation changes? Poof no more need for a timer.

Francis's explanations into the modifications I made are correct.

Francis deserves a lot of credit for putting this device together, and having a big enough heart to release it under the GPL. That's also the great thing about free, open-source, as Francis said - people can each work on the code to their strengths.

I don't have faith in a lagged sim automatically lowering timeslicing effectively... especially if already lagged. Also, for a device that needs to go from client to server distributed to other clients, there is already a lag created that a polling time of 100 times per second versus 4 times a second really won't affect too greatly, from the client end. That's why I made that change.

The device was also set up with three listeners, including one on the open chat channel. This will *ALWAYS* create lag. I mod'd the code to listen on the non primary chat channel, reduced it to a single listener, and cleaned up the logical code for commands a bit.

Again, Francis deserves 99% of the credit here, but its always good to be thinking about lag issues in advance, as pointed out by Chromal and eltee.

And, as its free open source, if anyone wants to take my code and make it better - go for it! Its available in many places, including the store in Indigo.

Regards,

-Flip

Kurt,

You posted while I was writing. I think most of here realize that the ability to override the default Linden animations for walking, running, and so forth should really be made native to Second Life. For example, put a new tab under EDIT PREFERENCES and allow people to define - from any animation they have, even if no copy / no transfer - which to use. Or, perhaps, integrate as an new option in Gestures.

Regards,

-Flip

well those of us who protested the change in female sits (and who still kinda are rubbed the wrong way over that whole issue) have been pushing for allowing that kinda persistant change to be in the GUI for months.. probably as part of the appearance editor outfit making or something along those lines...

we've gotten 'real soons'

but then we've been gettin them for nearly a year so i don't know how much that means

eltee,

Havok2 was implemented a few weeks after 1.4... this feature MUST be done already... just hiding somewhere!

-Flip

So is this the right place to ask for where I can get an somethin' - object, script, magical bubble gum - that'll let me change my sit pose to one of the cute ones I've bought without me having to open it up from my inventory every-time?

There are many ways of looking at the issue, but personally I'm kindof skeptical about server-side lag. With the exception of certain effects with physics (ie linked chains), I've never particularly noticed lag arising from sim CPU. Now, it probably does depend on the person - someone in SF might see things differently - but personally my primary sources of lag are:

1. network This is the Number One source of lag, and it effects two things:
   1. responsiveness in high avatar environment since each avatar is increasing your network load
      
   2. lag associated with downloading the world as you move through it, logon or teleport
      
   
   
2. client memory Theres a lot of objects in an SL sim. If you have < 512meg of memory, paging to disk is significant.
   
3. client CPU/graphics Depending on graphics options, rendering a sim 50 times a second takes its toll. Particles are particularly devastating on my own machine, but some of the graphics options (eg anti-aliasing) all take their toll
   

Azelda

Ok, since everyone seem to be doing it lately, I decided to open up and go over the FO script code as well.

My resolve: Francis made a great job.

Its efficent, its well coded, its damn good. I'm impressed.

Earlier on this thread Francis posted afew points about Sim resources and timers: I agree with her points. I have recently released my own product which have gone popular and is in common use, and evidence shows that what she is describing is in effect happening just as she described.

On regards to resource stealing: Yup. No one is "stealing" anything. The script is limited by its own functions. Putting a lower-then-the-minimum timer value is just a comfy way to make sure the script will always use the allowed minimum - not that it matters since it will never reach it due to the Sim itself.

Dont believe? Ask a Linden.

And finally... regarding GPL: Eltee... I suggest you take Flipper as an example.
True - GPL means that the author may incorporate your fixed code in the original script. However! For that to happen, the following 3 states must be true:

1)You must sit and actually make that code, yourself.
2)You must submit said fixed code snippet to the author.
3)The author can accept or reject your code snippet.

If you think you can do it... please. Go ahead and do it. o.o