#SL Server/Scripting News Update Wk5

The work is the roll out from Magnum to the main grid went well. The LSL function llSetRegionPos() is now on the main grid. Oskar says this is Kelly’s first major roll to the main grid for 2012. Yay Kelly.

Server/Scripting Meeting

Ghosting – Can’t Login

Two of the release channels were running a release that had ghosting problems in week 4. The problem was in the new foundational region crossing code. Carmilla Linden fixed the problem. When they merged the fix with the release code for Magnum, a crashing issue was found. The roll of the repaired code had to be foregone. So, that code planned for Magnum was replaced with the same release as Blue Steel and Le Tigre.

List Functions

The release code with the new and improved  and reimproved list functions has returned and is running in all three release channels. Kelly improved the performance of the list handling functions by several orders of magnitude. When first released a crasher was found. The code went through some iterations and has now returned to the release channels.

So, far it seems to be working well. Get over to the release channels and test your scripts that use lists. If all seems well it will roll to the main grid. I suspect since it is on all three channels the changes are getting a pretty good work out. More testing is always helpful.

You can compare performance in the main channel with performance in the release channels. The release channels should be way faster.

You may see Oskar start a thread about the new functions in the SL Forum.


SVC-7631 – New rate throttle on llGiveInventory. This change has caused some drama and blowback.

Kelly Linden commented in the JIRA and I’ve seen the words repeated in the forum.

Unfortunately some mailing list and product updaters may break or need to be updated. To stop a griefing mode that has effects on the entire grid’s back end infrastructure a throttle was added to llGiveInventory. This throttle matches (but is separate from) the existing throttle on llInstantMessage and exists for nearly identical reasons. That throttle is 5k per hour per owner per region; the maximum burst is 2.5k. It is impossible to hit this limit with a single script, but systems designed to spam very large amounts very rapidly may hit it and need to be adjusted. We will be monitoring the effect of this throttle to adjust it as we can if needed.

Security issues like this, especially of this grid wide severity, require that we act swiftly and without significant prior notice, for which we do apologize.

We term it a throttle however depending on the way the parameters are set up it can act more like a wall. Once the specified rate limit is reached sends will fail until the rate has fallen below the limit.

To be more clear, if the throttle were 1 per 1.3 seconds (roughly 5k / hour) then it would block any requests past that first one until the window had completed then let you make another request. However we find in practice that it is useful to allow as much ‘burst’ as we possibly can. In this case the rate is 5k / hour with a max burst of 2.5k. You can send 2.5k in the first minute, but will need to then wait a half hour before you could send more. We track in windows 1/2 the length of the overall rate, with the previous window biasing the current window – this is what leads to the effective rate of 5k / hour. Hopefully that clears things up, but it may not.

We definitely do prefer to announce changes like this in advance when possible. However when dealing with security issues of this scope (ability to effect grid wide stability and features) we sometimes must act quickly and without notice.

With 3k subscribers you will want to send slow enough that it takes ~45 minutes to send 1 item to each subscriber.

A general safe way would be to send ~2k as fast as you can, then wait 31 minutes and send another 2k.

Assuming nothing else owned by the same owner in the region is doing a significant amount of llGiveInventory and that the last 30 minute window has been relatively clear (ie also at or below 1/sec) then 1/sec should be a perfectly fine rate.

The throttle parameters are 2500 per 1800 seconds. The time starts at first send. We do an approximation of a rolling window where we take the current total, determine what percent of the window has passed and add a percent from the previous window to the current total. If you are 10% into the current window then we will add 90% of the previous total to the current total to determine if the action should be blocked, if you are 70% into the current window we will add 30% of the previous total, etc.

It is also important to note that blocked attempts still count towards the total.

This behavior means that a high burst could take up to 2x the window length to clear completely. After some investigation my previous suggestion of bursts of 2000 every 30 minutes may not work well in practice: At 1% into the next window we would be counting 99% of the previous window’s 2000 burst. It would be better to do it slower and more steady.

Would a lower burst rate but smoother throttle behavior be better in practice? For example a throttle of 250 per 180 seconds would set the max burst at only 250 but that burst would clear out of the history after 6 minutes. Or something in between – 500 per 360 etc.

There already is a 2 second sleep on llGiveInventory. The systems that are hitting the new limit are using many scripts to get around that sleep.

You noticed the ‘…’ ellipsis. Those are the places where I left out comments by others. Kelly’s comments provide the facts and values for using llGiveInventory(). There is a bit more information in #SL Server/Scripting News Wk5. Scroll down until you see llGiveInventory() Throttle.

If you missed it, the reason for the new restrictive throttle is from a griefing attack on the SL servers. That is also the reason there was little to no warning of the change.

Region Crossing Project

This is the project that had the ghosting (agent present) bug. It is repaired and waiting to roll to a release channel next week (Week 6).


SCR-243llCastRay returns RCERR_CAST_TIME_EXCEEDED until the sim is rebooted. This problem is delaying acceptance of the function. Oskar and Mæstro don’t know what is going on with the fix.

Direct Delivery

Rumor is that Direct delivery is starting the Release Channel process. So, we may see it moved to a release channel soon. Until then you can get the Direct Delivery Project viewer and test DD on the ADITI grid.

Summing It Up

We seem to be getting back into the swing of weekly roll outs.

Leave a Reply

Your email address will not be published. Required fields are marked *