Script Scheduler: Point, Counterpoint

I'd like to hear some feedback on the new script scheduler in here. As per the rant thread I just created, I'd like to hear some experiences on working with the thing from the mid-and-oldbies.


What do you folks think? Because personally, I have had nothing but problems with the thing eating my commands. Are these experiences shared?

Yes, the experience is shared . The scheduler has it's good points, it really does, and the intended purpose was a good one, but it just is causing too much grief to justify the way it works now. I'm not really sure what can be done to allow the scripts to run faster and keep lag at a minimum. I still think letting a sim turn to molasses because of bad coding will make scripters understand they *have* to optimize. But this again opens the door to script hogs and griefers who like to run up all the cpu cycles. Like I said, I can't offer a solution to the problem, but I think crippling scripts to stop a few script hogs is a bad idea. Maybe we should just have a better way to *sniff* out what exactly is causing the script lag in each sim.

</2cents>

How about giving landowners a way to get a list of top-cpu scripts in their parcel?

How about prioritizing execution per parcel or something that would guarantee you get 1/2 the cpu cycles if you own 1/2 a sim?
Maybe if/when Mono arrives there will be enough of a performance increase that the new scheduler wont really matter.

Not at first, but with all the extra speed, i'm sure we can think of ways to use it. <++

Whilst it's possible they'll completely reoverhaul the workings of the servers and take out the script scheduler I suspect it's not likely, at least not any time soon.

Given that what would help?

I've had some thinking time today and what I'd like to see is a two-part system.

One, on compiling the compiler makes an estimate of the ips score for the script. It won't be perfect, but you could, for example, look at how much processing time the commands take, (some trickier than others) and give at least an indication that this is a light, medium, heavy or obscene resource hog. It would have to be an estimate - an open listen on channel 0 on an island with only one av permitted access would hog far less than in The Edge or whatever's top of the dwell lists at the moment for example, but it would be an indicator and it might make us go back and rethink sometimes, at least the conscientious ones amoung us.

Two, we have an accessible record of the instructions ACTUALLY executed by each script, presumably in ips terms, with averages for the last minute, hour and day perhaps. This could, of course, get really detailed so we work out whether giving an inventory list as one is better or worse than having a list and giving each item separately. We have hard data that says one listen with a load of if-then's to parse the message is better or worse than a separate listen for each.

There will still be the wombats that just plough on but this way a conscientious scripter and, if the stats are accessible to the owners, worried land owners can see which scripts are better on their land.

As a separate aside, I'd like to see the scheduler do something differently if possible: I'd like to see it have a ring fenced area for local land owner's scripts, say 50% of the available time can only be used by scripts running from the local landowners. I'm less bothered about this being split by area owned but I guess it's a logical extension and I certainly don't object to it. I don't frequent The Edge or similar but this would help minimise some griefer hits and would mean that some of the more popular places actually had space for their stuff to run more or less to time despite the dance bracelets, bling, etc. being used. In quiet places it would also mean that the more responsible land owners would have their stuff running smoothly, and anyone who goes overboard might be OK, but might be in trouble with the timings if they have a load of visitors one day.

llSayWithAffect(0, AFFECT_BROKEN_RECORD, "Don't bet on Mono being a performance increase";