measuring script lag?

Please post your thoughts on objectively measuring script lag in a region.

I have a script that sends itself a message and shows the delay (current and LP filtered). And those of us with estate tools can look at top scripts. (I'll send this to anyone who asks, and perhaps post it on SLX or make it easily available.)

What else could we measure?

If what we're told about sim CPU time allocation is correct, scripts can't cause physics or display lag, except as secondary effects (by moving things or making particles). Do you have good evidence that this is true or false?

This info would be handy to scripters who take care with efficiency. It also might be helpful to compare before & after Mono.

Also, I've long suspected that scripts could contribute to chat lag (e.g., by having too many open listens). What are your thoughts?

Thanks
Jeff

The simulator has about 22ms per frame available to do its tasks.

It does whatever needs done and assigns the remaining time to process scripts.

Therefore scripts cannot cause lag, but can be lagged or rather run slow depending on what else the sim has to take care of.
Though some scripts can be quite demanding and gobble up a good part of the available time which makes other scripts "lag" or run slow.

Many listens or unfiltered channel 0 listeners do add to the processing time per frame and ths take away from the available script time.

And don't forget to vote for SVC-835 while you're here...

if by script lag you mean how slowly the script is running compared to how fast it should be?

I would think comparing a snapshot of llGetTime() and llGetUnixTime() should be pretty close or at least give you a nice average over time.


as for scripts not lagging the sim, I respectfully disagree. while the code itself is designed to run within that leftover window, not all the effects of those calls are limited to that window...

filtered listens would be one, as the server level filtering does not seem to occur within that scripting time window.

physics would be the biggest one, especially putting objects into motion.... but even something as simple as changing a prims position or size can trigger changes in bounding boxes and physics.

changing inworld data, whether it be textures, chat, or a size or position change, all these things must be trasmitted on to each avatar capable of experiencing them which adds overhead to scripted actions that are definately outside of the scripting window.

it might be true that the instructions are given a limited slice to run, but the effects of those instructions (as demonstrated by several fun scripted physics bombs) can bring a sim to it's knees.

That's my understanding, based on what I read on this forum. However, it's bluntly contradicted by an LL blog entry that says that Mono will reduce lag. I suspect that whoever posted that was in error, or was only referring to script lag.



Yes, but is all normal chat handled in script-processing time? I suspect not, and I suspect that *some* processing associated with listens happens outside the script slice. Whether it's enough to cause chat lag, I can only guess.

IMHO, the main problem with listens is invoking a script which then does nothing, taking script time, which is another thing entirely. In other words, it's not the listen per se, but invoking the script's listen handler. Mostly speculation on my part, of course.

Thanks!

That's simply time dilatation, right? What I want to measure is the effects of bad scripting, but *ignoring* the inworld issues you mention below. But yes, measuring how slowly a script is responding, for any reasons that would cause it to be slow to respond to various events.

Which means we do *not* disagree. I was sweeping a fair amount of things into "secondary effects", and that includes all the below, with the notable exception of server-level listen filtering.



True, but it's the other component that I'm more interested in measuring. I doubt there's a good way to measure the secondary effects.

Such scripts generally aren't accurate since script lag at the sim level changes based on what the current scripts are doing...
ie. perhaps when you checked the temp rezzers weren't rezzing
or maybe that sensor script was temporarily off
or maybe the sim had no avatars with AOs at the time
or maybe...

There are dozens of things which would throw your reading way off.

more specifically it's the average dilation for that specific script, which can vary from script to script and therefore vary from the time dilation reported by the server. as bobby points out, time dilation may(does?) affect heavily proccessing scripts more than mostly idle ones.


as for measuring secondary effects of script actions on sim lag.... it'd be nigh on impossible to do via lsl, in a very heisenburg way. but maybe indirectly, by looking at a sim with objects only, adding in scripts with the secondary effects I mentioned, and then monitoring physics, client load, and sim fps.... keeping in mind that many physical changes have a per avatar overhead for viewer updates, since I don't think changes are forwarded then broadcast by a another machine (though that would limit sim processing, it'd add latency and complexity, nevermind cost)

I've found the following to take up a LOT of script time that can definitely cause notable effects on the user experience:

1.) Any parallel processing to work around script delays, especially smooth non-physical movement (a bunch of scripts in paralllel all calling llSetPos() or llSetPrimitiveParams() or something similar to move an object smoothly despite the script delay imposed by these calls).

2.) Believe it or not, simple HTTP request processing using data server calls (yes, a simple script that downloads a list of keys every 20 seconds, requests online statuses for the associated residents, and uploads the data again while asking for the next set can take up a huge amount of script time for some reason, even if the keys are processed sequentially, no chat output or object data is dealt with, etc.).

3.) Frequent unfiltered (by key/name) sensors run with maximum range and arc.

There were sim scanning radar objects that were very popular for a while. They employed both frequent long-reaching sensor sweeps and non-physical movement to deploy multiple probes across a sim. You could just about smell when those things were turned on. They almost always appeared high on the Top Scripts dialog, and I've never seen a sim at 0.99 to 1.00 time dilation while they've been in use. (The above JIRA enhancement certainly got my vote.)

http doesn't suprise me, but sensors caught me off guard, though I can see the rationale.... taking a snapshot of position and rotation data for each object sensed probably leans on the physics engine, although I'm wondering if a filtered listen would make it any better really .. guess it depends on the order the sim does filtering. if it occurs before populating the data for the detected objects, then it'd help, otherwise it might actually hurt....

other things that likely contribute, would be any off sim call, e-mail, notecard reads, any dataserver use, rpc, etc, since outside communications are probably not included in script processing slice either.

camera controls would be another likely candidate since they'd be getting/sending their information either from/to the physics engine, or the individual client, or both.

take controls is less clear, but may suffer the same drawbacks depending on how the key interactions are reported to the script.

give inventory interactions may even have some minimal impact, depending on the routing of requests, if it has to process from the the sim to the client, then back through the sim to the asset server, and back through the sim... well you get the idea.

even particles sounds and animations have some effect, needing to be sent to all the avs able to experience them

What surprises me about HTTP and dataserver events is that that kind of I/O is usually pretty slow, and in most thread heavy applications will generally block while other processing is done. Thus I wouldn't expect it to slow down overall simulator performance so greatly. The timeliness of those events really shouldn't be relied on, but I AM surprised it has such a large effect in general.

Thus sampling and filtering. By "LP filtering" I mean low-pass filtering using the digital equivalent of an RC (resistor-capacitor) filter.

I totally believe that batched parallel nonphy moves can lag a sim! But I suspect the main reason is the physics updates, done in a way that can't be internally optimized (as physical movement could be).

It's too bad that "top scripts" doesn't provide low-pass filtered values, which would be far more useful than the snapshots that we get. It would also be great if they would sort by descending cpu time by default! I mean, who's the idiot that thought a random order would be helpful, and we have to click 3 times to get a sorted refresh rather than one! Someone was asleep at the wheel there.

Goodness knows how many people just look at the output and assume the top ones (or the biggest numbers they see on the screen) are the major offenders.

oops sorry, rant over.