[slscripters] Where do I find IM traffic limits?

Sasun Steinbeck sasunsteinbeck at gmail.com
Sat Oct 8 12:17:46 PDT 2011

I have often wondered if this limit is different on homestead sims, is the
throttle the same regardless of homestead vs. full sim?

On Tue, Sep 13, 2011 at 9:10 AM, Kelly Linden <kelly at lindenlab.com> wrote:

> The effective throttle rate is 5000 per hour. The logic is the same as most
> of our throttles, a rough sliding window.
> Actual implementation details:
> * The throttle is on all IMs from the object owner. It does not disable all
> IMs in the region, but does disable all IMs from the owner of the object.
> * The throttle is not per object, but per owner. Splitting the spamming
> object into multiple objects will not help unless owned by different people.
> This also means that owning multiple almost too spammy objects will cause
> you to hit the limit.
> * 2500 IMs in 30 minutes will trigger the block.
> * IMs that are blocked continue to count against the throttle. The IM count
> must drop below 2500 before any IMs will be delivered.
> * The IM count of the previous window is used to approximate the rolling
> window. If it is 20% into the current window the IM count will be the
> current count + 80% of the previous count. This allows us to approximate a
> rolling average, however it has the behavior that a flood of IMs can have an
> effect on the throttle for double the window length. This is why in practice
> the throttle behaves more like 5k in 1hr than 2.5k in 30min.
> Caveats:
> * There was a bug that is fixed in the today's release and will be fixed on
> all regions by the end of the week. This bug used the same throttle for IMs
> from objects as IMs from residents. So if you had a spammy object that hit
> the throttle you couldn't even send IMs from your viewer in that region.
> This is fixed on the release channel today and all regions by the end of the
> week. With this fix IMs from viewers have their own bucket and won't be
> blocked because of spammy objects, and visa versa.
> Why the limit?
> * Flooding IMs can be detrimental to the system and cause undue load on the
> region and back end servers. In severe cases this can lead to region
> crashes, viewer crashes and inventory/content loss. The throttle is in place
> to prevent this.
>  - Kelly
> On Tue, Sep 13, 2011 at 8:13 AM, AnnMarie at SLFBI.com <AnnMarie at slfbi.com>wrote:
>> Ah yes, I have to agree, Fred.  It is inconceivable that I sent out
>> 5,000 IMs but burst rate could get up to a theoretical absolute maximum
>> of 40 per second followed by 2 seconds silent or an average of 20 per
>> second.  It should not be hard to set up some tests and see what it
>> takes to trip the alarm.  I will do that and publish the results.  Once
>> I know the limits it won't be difficult to put in a safety valve.
>> So the penalty in addition to capping, is to lock out all IMs from
>> objects owned by the perpetrator for an hour.  That suggests that
>> objects like this should be "owned" by an alt.  That way you don't risk
>> shutting down all your vendors and other items if you trip the alarm.
>> Or do they recognize the alt and penalize the owner's owner too.  I
>> guess I'll find that out too with my tests.
>> Yes it appears to be an anti-griefing motive for having a 1 hour cap on
>> all objects when a cap on the offending object should be sufficient.
>> AnnMarie Otoole
>> On 9/13/2011 10:33 AM, Fred Allandale wrote:
>> I did some experimenting a while back with IM sending rate caps and
>> discovered that not only does the 5000 IMs per hour limit apply, but there
>> is also a shorter term burst rate that will trip the same alarm.  So you
>> can't get around the problem by loading up the object with a bunch of IM
>> sending scripts and send out 4999 IMs in 10 minutes.  I was never able to
>> find any information on the short term burst rate limit or determine
>> what it
>> is by experimenting.  I do know that having an object send IMs at 10 per
>> second will trip the alarm in less than one minute.  Also, the limits
>> appear
>> to apply to the total IMs sent from all the owner's objects within the
>> region, not per object (the error message says "objects" - plural). In a
>> product that I sell, I limit the object IM send rate to 1 per second and
>> have only had a few occurrences, and I think they were caused by multiple
>> objects sending IMs at the same time. I would love to have it send faster
>> (and so would my customers), but because the limits are not published,
>> there
>> is not a safe way to maximize the send rate while minimizing the the
>> chances
>> of tripping the alarm and shutting down all objects for that owner in the
>> same sim.  I was once told the limits are not published so as not to tip
>> off
>> griefers, but it also limits the usefulness of legitimate products.
>> _______________________________________________
>> Click here to unsubscribe or manage your list subscription:
>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
>> _______________________________________________
>> Click here to unsubscribe or manage your list subscription:
>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/secondlifescripters/attachments/20111008/73807dd1/attachment.htm 

More information about the secondlifescripters mailing list