Skip to content
This repository has been archived by the owner on Feb 28, 2024. It is now read-only.

[BUG-6053] Change interest list such that rapid updates from rapidly-changing objects have less impact on updates from other objects #13944

Open
sl-service-account opened this issue May 16, 2014 · 7 comments

Comments

@sl-service-account
Copy link

sl-service-account commented May 16, 2014

Steps to Reproduce

1.) Create an object with over 64 primitives and link it (Ctrl + L).

2.) Create a New Script and run it:

default
{ 
    state_entry()
    {
            llSetTimerEvent(0.1);
    }
    timer()
    { 
        float x = llFrand(1.0);
        float y = llFrand(1.0);
        float z = llFrand(1.0);
        llSetLinkColor(LINK_SET,<x,y,z>,ALL_SIDES);
    }
}

3.) Open your viewer statistics(Ctrl + Shift + 1) and observe your Bandwidth jump from the average 20 - 80kbps to 600-1000kbps.

4.) Disable the script and observe the bandwidth has dropped back to 20-80kbps.

5.) Attempt to rez new objects via a scripted item(HUD or weapon) while the script is running, and observe the new objects or bullets do not render.

Actual Behavior

Using llSetLinkColor to change the colour every 0.1 seconds on a object with more than 64 primitives causes Bandwidth issues for all users who have it rendered, making new objects within the region not render.

Expected Behavior

Bandwidth to not jump between 600kbps - 1000kbps for every user that is within render distance, and disabling them to render new objects.

Other information

Related to Support Ticket: 01920280
Date Created May 15, 2014, 2:33 p.m.
Case Type Region Performance Issues

Whether it is attached or not it still creates bandwidth issues for those in the render distance of the object, using llSetLinkPrimitiveParamsFast and llSetLinkPrimitiveParamsFast still causes the same issues, and obviously linking more primitives causes more bandwidth demand. Doesn't matter what Secondlife Viewer you on, third party or not still causes the bandwidth to jump.

Here are some text scripts below that you can toggle on and off:

//llSetLinkColor

integer on;
default
{ 
    state_entry()
    {
        llSetText("llSetLinkColor();",<1,1,1>,1);
        llSetTimerEvent(0.0);
        on = FALSE;
    }
    touch_start(integer num)
    {
        if(on == FALSE)
        {
            llSetTimerEvent(0.1);
            on = TRUE;
        }
        else if(on == TRUE)
        {
            llSetTimerEvent(0.0);
            on = FALSE;
        }      
    }
    timer()
    { 
        float x = llFrand(1.0);
        float y = llFrand(1.0);
        float z = llFrand(1.0);
        llSetLinkColor(LINK_SET, <x,y,z>,ALL_SIDES);
    }
} 
//llSetLinkPrimitiveParams

integer on;
default
{ 
    state_entry()
    {
        llSetText("llSetLinkPrimitiveParams();",<1,1,1>,1);
        llSetTimerEvent(0.0);
        on = FALSE;
    }
    touch_start(integer num)
    {
        if(on == FALSE)
        {
            llSetTimerEvent(0.1);
            on = TRUE;
        }
        else if(on == TRUE)
        {
            llSetTimerEvent(0.0);
            on = FALSE;
        }      
    }
    timer()
    { 
        float x = llFrand(1.0);
        float y = llFrand(1.0);
        float z = llFrand(1.0);
        llSetLinkPrimitiveParams( LINK_SET,[PRIM_COLOR, ALL_SIDES, <x,y,z>,1.0]);
    }
} 
//llSetLinkPrimitiveParamsFast

integer on;
default
{ 
    state_entry()
    {
        llSetText("llSetLinkPrimitiveParamsFast();",<1,1,1>,1);
        llSetTimerEvent(0.0);
        on = FALSE;
    }
    touch_start(integer num)
    {
        if(on == FALSE)
        {
            llSetTimerEvent(0.1);
            on = TRUE;
        }
        else if(on == TRUE)
        {
            llSetTimerEvent(0.0);
            on = FALSE;
        }      
    }
    timer()
    { 
        float x = llFrand(1.0);
        float y = llFrand(1.0);
        float z = llFrand(1.0);
        llSetLinkPrimitiveParamsFast( LINK_SET,[PRIM_COLOR, ALL_SIDES, <x,y,z>,1.0]);
    }
}  

Attachments

Original Jira Fields
Field Value
Issue BUG-6053
Summary Change interest list such that rapid updates from rapidly-changing objects have less impact on updates from other objects
Type New Feature Request
Priority Unset
Status Accepted
Resolution Accepted
Reporter James Benedek (james.benedek)
Created at 2014-05-16T15:02:34Z
Updated at 2014-05-22T18:22:02Z
{
  'Business Unit': ['Platform'],
  'Date of First Response': '2014-05-16T10:47:48.676-0500',
  'How would you like the feature to work?': '.',
  "Is there anything you'd like to add?": 'Related to Support Ticket: 01920280\r\nDate Created May 15, 2014, 2:33 p.m.\r\nCase Type Region Performance Issues\r\n\r\nWhether it is attached or not it still creates bandwidth issues for those in the render distance of the object, using llSetLinkPrimitiveParamsFast and llSetLinkPrimitiveParamsFast still causes the same issues, and obviously linking more primitives causes more bandwidth demand. Doesn\'t matter what Secondlife Viewer you on, third party or not still causes the bandwidth to jump.\r\n\r\nHere are some text scripts below that you can toggle on and off:\r\n\r\n//llSetLinkColor\r\n\r\ninteger on;\r\ndefault\r\n{ \r\n    state_entry()\r\n    {\r\n        llSetText("llSetLinkColor();",<1,1,1>,1);\r\n        llSetTimerEvent(0.0);\r\n        on = FALSE;\r\n    }\r\n    touch_start(integer num)\r\n    {\r\n        if(on == FALSE)\r\n        {\r\n            llSetTimerEvent(0.1);\r\n            on = TRUE;\r\n        }\r\n        else if(on == TRUE)\r\n        {\r\n            llSetTimerEvent(0.0);\r\n            on = FALSE;\r\n        }      \r\n    }\r\n    timer()\r\n    { \r\n        float x = llFrand(1.0);\r\n        float y = llFrand(1.0);\r\n        float z = llFrand(1.0);\r\n        llSetLinkColor(LINK_SET, <x,y,z>,ALL_SIDES);\r\n    }\r\n} \r\n\r\n\r\n//llSetLinkPrimitiveParams\r\n\r\ninteger on;\r\ndefault\r\n{ \r\n    state_entry()\r\n    {\r\n        llSetText("llSetLinkPrimitiveParams();",<1,1,1>,1);\r\n        llSetTimerEvent(0.0);\r\n        on = FALSE;\r\n    }\r\n    touch_start(integer num)\r\n    {\r\n        if(on == FALSE)\r\n        {\r\n            llSetTimerEvent(0.1);\r\n            on = TRUE;\r\n        }\r\n        else if(on == TRUE)\r\n        {\r\n            llSetTimerEvent(0.0);\r\n            on = FALSE;\r\n        }      \r\n    }\r\n    timer()\r\n    { \r\n        float x = llFrand(1.0);\r\n        float y = llFrand(1.0);\r\n        float z = llFrand(1.0);\r\n        llSetLinkPrimitiveParams( LINK_SET,[PRIM_COLOR, ALL_SIDES, <x,y,z>,1.0]);\r\n    }\r\n} \r\n\r\n\r\n//llSetLinkPrimitiveParamsFast\r\n\r\ninteger on;\r\ndefault\r\n{ \r\n    state_entry()\r\n    {\r\n        llSetText("llSetLinkPrimitiveParamsFast();",<1,1,1>,1);\r\n        llSetTimerEvent(0.0);\r\n        on = FALSE;\r\n    }\r\n    touch_start(integer num)\r\n    {\r\n        if(on == FALSE)\r\n        {\r\n            llSetTimerEvent(0.1);\r\n            on = TRUE;\r\n        }\r\n        else if(on == TRUE)\r\n        {\r\n            llSetTimerEvent(0.0);\r\n            on = FALSE;\r\n        }      \r\n    }\r\n    timer()\r\n    { \r\n        float x = llFrand(1.0);\r\n        float y = llFrand(1.0);\r\n        float z = llFrand(1.0);\r\n        llSetLinkPrimitiveParamsFast( LINK_SET,[PRIM_COLOR, ALL_SIDES, <x,y,z>,1.0]);\r\n    }\r\n} ',
  'System': 'SL Simulator',
  'Target Viewer Version': 'viewer-development',
  'What just happened?': '1.) Create an object with over 64 primitives and link it (Ctrl + L).\r\n\r\n2.) Create a New Script and run it:\r\n\r\ndefault\r\n{ \r\n    state_entry()\r\n    {\r\n            llSetTimerEvent(0.1);\r\n    }\r\n    timer()\r\n    { \r\n        float x = llFrand(1.0);\r\n        float y = llFrand(1.0);\r\n        float z = llFrand(1.0);\r\n        llSetLinkColor(LINK_SET,<x,y,z>,ALL_SIDES);\r\n    }\r\n\r\n3.) Open your viewer statistics(Ctrl + Shift + 1) and observe your Bandwidth jump from the average 20 - 80kbps to 600-1000kbps.\r\n\r\n4.) Disable the script and observe the bandwidth has dropped back to 20-80kbps.\r\n\r\n5.) Attempt to rez new objects via a scripted item(HUD or weapon) while the script is running, and observe the new objects or bullets do not render.\r\n\r\n',
  'What were you doing when it happened?': 'Using llSetLinkColor to change the colour every 0.1 seconds on a object with more than 64 primitives causes Bandwidth issues for all users who have it rendered, making new objects within the region not render.',
  'What were you expecting to happen instead?': 'Bandwidth to not jump between 600kbps - 1000kbps for every user that is within render distance, and disabling them to render new objects.',
  'Why is this feature important to you? How would it benefit the community?': '.',
}
@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2014-05-16T15:47:49Z

I couldnt reproduce newly rezzed objects not rendering with just one of your repro objects rezzed on the region but with two rezzed, using the Library popgun, about 50% of the bullets fired failed to rez on my screen.

Could this be the same problem filed at BUG-665?

@sl-service-account
Copy link
Author

Darien Caldwell commented at 2014-05-16T19:54:03Z

So you make an object that behaves badly, and are surprised it behaves badly? No intentionally functioning product would ever change colors or textures on 64 prims every 0.1 second. Only a griefer would make something like that.

@sl-service-account
Copy link
Author

James Benedek commented at 2014-05-16T19:57:05Z

64 Prims changing colour is hardly a griefer tool. Nor should it cause such strain on bandwidth for a whole region.

@sl-service-account
Copy link
Author

Maestro Linden commented at 2014-05-16T23:12:33Z

Hi James, thanks for the report. I tried out your script, and do see that your script makes bandwidth usage increase to ~600kbps when my viewer has a high bandwidth limit set (I used 10000kbps). However, this is to be expected, as the objects are generating about 640 terse updates a second. I can decrease the bandwidth usage by lowering my viewer's throttle, which is effective but also limits the rate at which I see object updates from the objects.

I cannot reproduce the case where newly-rezzed objects do not appear, due to object update spam. While either one or two of these linksets is in view, generating many updates, I can't reproduce the issue where newly-rezzed bullets from the popgun don't appear. I tried this with my bandwidth setting at either extreme (100kbps and 10000kbps). In either case, the bullet motion is certainly less smooth, and sometimes the appearance of the bullet is delayed (especially at 100kbps), I have not run into the case where the bullet does not appear at all. My test viewer is 'Second Life 3.7.7 (289461) Apr 22 2014 14:17:15 (Second Life Release)' - do you see the seam behavior in this viewer version? It can be found here: https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Release/3.7.7.289461

If you can reproduce the issue with the 3.7.7.289461 release viewer, what is your packet loss statistic while objects fail to appear after rez? It occurs to me that if your bandwidth throttle is set higher than your connection actually supports, you may run into a packet loss situation, which may lead to undesirable results.

As an aside, if you enable Develop -> Show Info -> Show Updates to Objects, the viewer will illustrate object updates for you. This display mode is useful for identifying content which is causing high bandwidth usage.

@sl-service-account
Copy link
Author

James Benedek commented at 2014-05-17T06:06:51Z

Thanks for the tip Maestro, but as you can see in the screenshot I already have Show Updates to Objects turned on.

Within the third-party firestorm viewer I had my bandwidth throttled to 1000kbps, and this is my current connection speed on a bad day http://www.speedtest.net/my-result/3505761657. It's a 50mb/s connection.

On the 'Second Life 3.7.7 (289461) Apr 22 2014 14:17:15 (Second Life Release)' you have supplied yes I can reproduce this issue, but its even worse it at times doesn't seem to even update the avatars movement when the scripts are enabled and within the render distance.

The bullets we are using are high velocity (Travelling at 200.000 mps) and that's only why I can explain they are not rendering compared to popgun bullets that render a few meters away and don't update their physical movement during the spike of bandwidth. Here is a video I captured: https://www.youtube.com/watch?v=SBi_4rJO0u4

Second Life 3.7.7 (289461) Apr 22 2014 13:01:33 (Second Life Release)
Release Notes
You are at 236.7, 44.6, 50.6 in Westminster located at sim10107.agni.lindenlab.com (216.82.48.173:13015)
SLURL: http://maps.secondlife.com/secondlife/Westminster/237/45/51
(global coordinates 133,357.0, 230,445.0, 50.6)
Second Life RC Magnum 14.05.09.289913
Retrieving...
CPU: AMD Phenom(tm) 9650 Quad-Core Processor (2300.12 MHz)
Memory: 8192 MB
OS Version: Microsoft Windows 7 64-bit Service Pack 1 (Build 7601)
Graphics Card Vendor: ATI Technologies Inc.
Graphics Card: AMD Radeon HD 5700 Series
Windows Graphics Driver Version: 8.17.0010.1247
OpenGL Version: 4.2.12618 Compatibility Profile Context 13.251.0.0
libcurl Version: libcurl/7.24.0 OpenSSL/0.9.8q zlib/1.2.5
J2C Decoder Version: KDU v7.0
Audio Driver Version: FMOD Ex 4.44.31
Qt Webkit Version: 4.7.1 (version number hard-coded)
Voice Server Version: Vivox 4.6.0009.20030
Built with MSVC version 1600
Packets Lost: 0/1 (0.0%)

@sl-service-account
Copy link
Author

Maestro Linden commented at 2014-05-19T20:05:18Z

Thanks for the video illustration, James. I see what you mean - since the bullets move so quickly, the 1-2 second delay in their updates being sent in the flooded case means that you don't see them until they're quite far from the rez position. I saw similar delays in my earlier testing with the popgun bullets when I had a tight bandwidth throttle set, but the bullets always eventually appeared because they move slowly and linger after hitting the ground.

The high bandwidth usage is definitely expected when objects change appearance rapidly, so long as it doesn't exceed the throttle set in the viewer preferences. However, when object updates are being throttled, perhaps there should be a QoS system in place so that the object update messages are more 'fairly' balanced. What is 'fair' is open to some interpretation, though perhaps a per-linkset or per-object-owner (if you're worried about griefers) based throttle may be a good start. This would be a new feature, so I'm reclassifying this Jira.

@sl-service-account
Copy link
Author

Alexa Linden commented at 2014-05-22T18:20:12Z

Thank you for your suggestion.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant