Throttling and DEBUG_CHANNEL

[Love Zhaoying]

I've only recently started using DEBUG_CHANNEL to trace some scripts using llSay(DEBUG_CHANNEL,..).  Strangely, all these years I had been using llOwnerSay().

If my script sends too many messages to DEBUG_CHANNEL in too short a time, I've noticed it gets completely throttled - even a script restart won't produce any more output, even with recompiling or changing the script. I have to wait a little while before any output shows again.

Is this expected? I remember reading it somewhere but Google fail. (Guess I should check llSay()..) Also, is there a suggested workaround besides "just wait awhile" when I see the output to DEBUG_CHANNEL stopped completely even on a script restart?

[Fenix Eldritch]

Yes it's expected - it is the very first caveat on the llSay function's wiki page.

Quote

Caveats

• Messages sent on channel zero^[1] and DEBUG_CHANNEL are throttled to a rate of <200/10sec, per region, per owner/user.
  • Once the rate is exceeded, all following messages on channel zero or DEBUG_CHANNEL will be dropped until the send rate is again below 200/10sec for the previous 10 sec. Dropped messages, despite being dropped still count against the limit.

Further down the page in the notes section, it recommends using llOwnerSay as an alternative for debug purposes.

Also be aware that the debug channel is not private: anyone nearby will see it in the same script error section. If your object is talking on the debug channel so much it's getting throttled, you're kinda spamming anyone within llSay range. That's another reason why llOwnerSay might be preferable...

 

[Wulfie Reanimator]

4 hours ago, Fenix Eldritch said:

Also be aware that the debug channel is not private: anyone nearby will see it in the same script error section. If your object is talking on the debug channel so much it's getting throttled, you're kinda spamming anyone within llSay range. That's another reason why llOwnerSay might be preferable...

I was going to say this too, but after double-checking in-world, at least Firestorm only displays debug messages from objects you own. llSay to debug channel won't be seen by others, though the messages are still sent to everybody. (The filtering is done in llviewermessage.cpp)

[Frionil Fang]

30 minutes ago, Wulfie Reanimator said:

IllSay to debug channel won't be seen by others, though the messages are still sent to everybody. (The filtering is done in llviewermessage.cpp)

Objects are free of this restriction and can listen to the DEBUG_CHANNEL (spy on, as it were). Making one is trivial. That would be my only reason to use the DEBUG_CHANNEL (an object that can log debug messages externally while I'm not present), but why would I be using a well-known channel number like the DEBUG_CHANNEL in that case instead of a random hidden one (and one that doesn't get throttled as easily)?

[Love Zhaoying]

Thanks guys, as sometimes happens I forgot to follow the thread after I created it! * facepaw *

[Love Zhaoying]

5 hours ago, Fenix Eldritch said:

Yes it's expected - it is the very first caveat on the llSay function's wiki page.

Quote

Caveats

• Messages sent on channel zero^[1] and DEBUG_CHANNEL are throttled to a rate of <200/10sec, per region, per owner/user.
  • Once the rate is exceeded, all following messages on channel zero or DEBUG_CHANNEL will be dropped until the send rate is again below 200/10sec for the previous 10 sec. Dropped messages, despite being dropped still count against the limit.

Expand  

Further down the page in the notes section, it recommends using llOwnerSay as an alternative for debug purposes.

Also be aware that the debug channel is not private: anyone nearby will see it in the same script error section. If your object is talking on the debug channel so much it's getting throttled, you're kinda spamming anyone within llSay range. That's another reason why llOwnerSay might be preferable...

Darn it all! I should have looked at llSay(), thanks!

I only "recently" started using DEBUG_CHANNEL for exactly the reason that it works so great! 

- No timestamps or "who sent it" in the window, so you can copy/paste stuff as needed

Thanks for the heads-up on the "anyone nearby", I usually do this work on my own parcel and there is nobody anywhere near.

But definitely, because of reasons (see above), DEBUG_CHANNEL is  working for me better than llOwnerSay() (until the throttling came up and oops - now that I know others would see it too).

I started using DEBUG_CHANNEL on recommendation of someone here! 😉

 

[Love Zhaoying]

5 hours ago, Fenix Eldritch said:

Once the rate is exceeded, all following messages on channel zero or DEBUG_CHANNEL will be dropped until the send rate is again below 200/10sec for the previous 10 sec. Dropped messages, despite being dropped still count against the limit.

From my description - the throttling is much more severe than described above, once the throttle throttles.

 

8 hours ago, Love Zhaoying said:

even a script restart won't produce any more output, even with recompiling or changing the script. I have to wait a little while before any output shows again.

 

[Love Zhaoying]

Hmm! I can just add a delay between writes to DEBUG_CHANNEL, since I'm just using it for debugging anyway, and using a function for llSay(DEBUG_CHANNEL,..);

That should deal with for now.

Thanks again!

 

[Fenix Eldritch]

5 hours ago, Wulfie Reanimator said:

at least Firestorm

Ah, that's good to know. I tried this in-world with another user who is on the official viewer (took forever to find one, lol) and they didn't see my messages sent to the debug channel either. So the wiki is out of date in that regard...

 

The following was typed out before Love had made their last post, but I'll keep it here anyway.

4 hours ago, Love Zhaoying said:

the throttling is much more severe than described above

More severe in what way?

Keep in mind that once the throttle engages, any dropped messages still count against the total, so you have to stop the output to let it cool off before starting again. I did a quick in-world test and saw that once I get throttled, if I stop the messaging and wait for about 10 seconds, I can resume it and will see another 200 messages of output (until the throttle re-engages)

integer x=0;
integer toggle=FALSE;

default
{
    timer()
    {
        x++;
        llWhisper(DEBUG_CHANNEL,"beep boop this is a debug message - "+(string)x);
    }

    touch_start(integer total_number)
    {
        
        if (toggle = !toggle)
        {
            x=0;
            llOwnerSay("starting - "+(string)x);
            llSetTimerEvent(0.001);
        }
        else
        {
            llSetTimerEvent(0.0);
            llOwnerSay("stopped - "+(string)x);
            x=0;
        }
    }
}

As another test, I changed the stopped portion to instead drop the timer down to 0.06 seconds, which is just under the 200 per 10 seconds threshold. Once the throttle hits and I drop the rate to the slower interval, I begin to see messages again after about 17 seconds. This lower message rate seems to fly just under the throttle and will go indefinitely.

Also, note that the throttle is per owner, so if you have other scripts/objects outputting to the debug channel in the same region, I assume that's going to hit the throttle faster, and make it harder to relax it as well.

Edited September 15, 2022 by Fenix Eldritch
reworded for clarity

[Wulfie Reanimator]

I can't think of any throttling behavior that targets a specific script, especially the current lifetime of a script.

All of the throttles I can think of (llGiveInventory, llInstantMessage, llHTTPRequest) are applied to the whole object, objects in the sim, or all objects from the owner.

Edited September 15, 2022 by Wulfie Reanimator

[Quistess Alpha]

Another solution might be to llRegionSayTo a debugger object which holds the last few lines:

list gList;
//...
listen(...)
{  gList = llList2List(gList+("\n"+text),-10,-1); // rolling buffer of last 10 messages.
   llOwnerSay("\n"+text);
}
touch_start(integer n)
{   llOwnerSay((string)gList);
}

 

Edited September 15, 2022 by Quistess Alpha