[BUG-6053] Change interest list such that rapid updates from rapidly-changing objects have less impact on updates from other objects #13944
Comments
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? |
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. |
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. |
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. |
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) |
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. |
Alexa Linden commented at 2014-05-22T18:20:12Z Thank you for your suggestion. |
Steps to Reproduce
1.) Create an object with over 64 primitives and link it (Ctrl + L).
2.) Create a New Script and run it:
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:
Attachments
Original Jira Fields
The text was updated successfully, but these errors were encountered: