Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007252opensim[REGION] OpenSim Corepublic2014-07-04 09:582015-06-04 17:08
ReporterRobert Adams 
Assigned To 
PlatformOperating SystemOperating System Version
Product Versionmaster (dev code) 
Target Versionmaster (dev code)Fixed in Versionmaster (dev code) 
Summary0007252: Multiple right clicks in viewer causes lag
DescriptionIf you walk in a region and right click your mouse on the terrain while walking and then try to stop walking you will find that you are still walking and the region is un-responsive. Looking at the queues, the task output queue has been filled up and takes several seconds to empty.

This is not just walking but also gets in the way of editing as somehow the right click causes the lag.

This happens with old and new viewers (tried Phoenix even).
Steps To ReproduceWalk and right click multiple times on the terrain (getting the circular menu). Then try to stop walking. You will continue walking and input does not change the walking. Doing a "show queues" on the region shows that task packet queue with hundreds of messages queues.
TagsNo tags attached.
Git Revision or version number
Run Mode Grid (Multiple Regions per Sim)
Physics EngineBulletSim
Script Engine
EnvironmentMono / Linux64
Mono Version3.6
Viewerall tested
Attached Files

- Relationships

-  Notes
zadark (reporter)
2014-07-04 10:42
edited on: 2014-07-07 20:09

This behaviour is more pronounce with region size increase. Right click the terrain sends a 'ParcelProperties' event from the simulator. Parcel Properties contains a bitmap field that increases with region size. For a 256 x 256 region, bitmap contains 512 bytes. For a 1024 x 1024 region the bitmap contains 8192 bytes.

This is good demonstration of how viewer simulator management communications have a profound effect on performance.

zadark (reporter)
2014-07-07 20:09

Additional information.
Perhaps a little terse with the previous comment.
Right click on the terrain generates viewer to simulator message 'ParcelPropertiesRequest' the simulator responds with messages 'ParcelProperties' and 'ParcelOverlay'

'ParcelProperties' as per previous comment. 'ParcelOverlay' is a repeated message, each with a bitmap of 1024 bytes.
For each 256 x 256 sector 4 'ParcelOverlay' messages are sent. For a standard 256 x 256 this is just 4 messages, for 1024 x 1024 the message count increases
to (16 x 4) 64.

Lag is more pronounced during these data exchanges.

These messages are also generated when an avatar enters a region, login, teleport or HG
justincc (administrator)
2014-07-09 15:44

On a local test with Singularity 1.8.5 on Linux 64-bit, I can't reproduce the issue with holding down the RMB generating a large number of inbound ParcelPropertiesRequests. Requests only get generated when I actually right click (as seen with the "debug lludp packet 1" console command). I tried both a 256x256 and a 512x512 region.

That said, it is the case that this is a test with both viewer and simulator on the same machine, so even a lot of data is going to be delivered quickly. Are you doing these tests where the simulator is on a remote machine or over the Internet?
Robert Adams (administrator)
2014-07-09 21:33

I did my testing with a 1024x1024 region connected to OSGrid ("BulletSim44"). I'd suspect having a high speed connection would reduce the lag effect. OSGrid could also have bandwidth to the viewers reduced.
Twitch (manager)
2015-03-07 10:00

I can confirm this. However, I have noted a profound increase sensitivity to this issue when relocating to osgrid from an offline test grid. Both regions in question are at some not inconsiderable remove on the internets. Both operated from the same server, though opensim code was updated for reconnection to osgrid.

My client connection speed has not changed.
cuteulala (reporter)
2015-03-20 17:38

Unfortunately this bug still persists and its VERRY annoying here is a video of it still happening i cant work on vars because of this lag [^]
Gavin Hird (reporter)
2015-03-21 00:16

I have seen something similar to that on the 0.8.1 dev+release code with version 2 viewers, but for the latest version of the Kokua viewer they managed to clean it up so it runs without the flooding.

Latest version from [^]
dahlia (administrator)
2015-03-21 00:41

I tried and tried but I can't reproduce this. RIght clicked many times on both terrain and objects, no lag.
Twitch (manager)
2015-03-21 04:05

Notice how after you right click and then walk *your avatar does not animate* this is one of the symptoms. You will find that 'sit text' does not display in the pie menu correctly while this semi-blocking is happening, and if you sit before you get the proper sit text in the menu, unpredicatble things happen and you will spend time at <0,0,0> until it settles out.

Additionally, items copied with shift+drag may fail to rez in a timely fashion, changes made to scripts while the semi-blockage is in effect have to 'catch up' once things settle, etc.
OtakuMegane (reporter)
2015-03-21 08:08

Decided to give this a try on a normal region and a 768x768 var region I have. Both are on a remote server connected to OSGrid.

On the normal region I was unable to reproduce the problem. If there was any effect it was too brief to detect. On the var region however it was very easy to cause the lag with just a few clicks. The more times I clicked in succession the worse it got; 3-4 clicks added about 1 second more lag. As a single user it probably wouldn't be an issue but if clicks from multiple users stack that could cause problems.

Tested using Singularity. The server is on a gigabit connection and my home connection is 6mbps down and 55ms ping to the server.
cuteulala (reporter)
2015-03-21 13:40

This is a SEVERE issue that needs sorted i am desperate to play on vars lol
kenvc (reporter)
2015-03-26 18:45

I can confirm this is happening in all of the vars where I build too. The longer you work, the slower it gets. I have not noticed this issue on normal sims, only when building on vars.
jozee tungsten (reporter)
2015-03-27 22:42

This issue has been happening on vars for a very long time. I first noticed it happening well before the OSGrid crash. It happens with all viewers except Cool viewer. I see it as more of an edit issue than a lag issue; it starts to occur right after ending an edit session: you cannot move, fly or edit, but rotation still works. It sometimes resolves itself after a few minutes. You can work around by restarting the UDP server with the debug commands.
Robert Adams (administrator)
2015-03-28 07:06

My theory is the lag is caused by the simulator sending the parcel information to the client on every right click. The parcel information is for permission checking and parcel information display. The information for the whole region is sent to the viewer so the larger the region, the larger the parcel packet. For 256x256 parcels, the information is not that large and sending a bunch (on every right click) doesn't slow people down but when the region is large (1k x 1k is 16 times larger) multiple parcel information packets start to clog up the pipeline. They may also be being sent in a packet bucket that is getting throttled.

I think the information is sent just to make sure the viewer has the latest information. The solution is to fix the code to only send the parcel info if it has changed or if some time has passed.
jozee tungsten (reporter)
2015-04-28 09:35

I did some digging into the code and determined that the problem is caused by a Parcel Overlay Request from the client. This causes SendParcelOverlay in LandManagementModule to create a byte array from the entire region. This is subsequently sent sequentially back to the client unthrottled. Which is enough to totally flood the packet pipeline on a large var running on a home installation. I have an 8x8 var running on home ADSL, and a few seconds of edit of anything would totally freeze my avi and preclude subsequent access to the edit menu. I set an upper limit on the array size and set the routine to run once every five minutes. This alleviated the problem on my build, but I obviously am not in a position to do any further testing.
Misterblue (reporter)
2015-04-28 13:32

I agree with your assessment. I am testing some code that only sends the parcel layer info around the area of interest. The real solution is some system of only sending it if it changed but that is more difficult. I am also concerned about making sure the whole region info is sent on login and parcel updates (selling, etc).

I should have the partial parcel info update inchecked in in a few days.
Robert Adams (administrator)
2015-05-03 22:35

I checked into the OpenSimulator sources a fix for the large varregion 'right click lag' problem. The solution only sends the parcel layer data around the click location.

Turned out that OpenSimulator used to send the whole region's parcel layer data (for sale, permissions, ...) when any interaction with the terrain happened (like right clicking somewhere). For a 256x256 region this was about 4K of data. For a 4kx4k varregion, this was > 1MB and, after several right clicks, the transmission queues would fill up.

The long term solution is to only send parcel layer data when it changes but, in the short term, this 'fix' sends only the parcel data around the place clicked. The parcel layer distance defaults to 128 so operation for legacy sized regions will be what it has always been.

The operation is controlled by parameters (added to OpenSimDefaults.ini):
    LimitParcelLayerUpdateDistance = true
    ParcelLayerViewDistance = 128

The whole region's parcel layer information will continue to be sent for parcel updates, and other major changes. This is as it has always been.
OtakuMegane (reporter)
2015-05-04 14:28

Been trying out the fix and so far I can't trigger the lag issue on a 768x768 any more. Haven't tested it on a larger var. When subdividing and joining parcels as well as changing parcel info everything updates properly as it did before.
cuteulala (reporter)
2015-05-04 22:24

this issue is resolved comfirmed by dan banner

- Issue History
Date Modified Username Field Change
2014-07-04 09:58 Robert Adams New Issue
2014-07-04 10:42 zadark Note Added: 0026426
2014-07-07 20:09 zadark Note Added: 0026451
2014-07-07 20:09 zadark Note Edited: 0026426 View Revisions
2014-07-09 15:44 justincc Note Added: 0026459
2014-07-09 21:33 Robert Adams Note Added: 0026461
2015-03-07 10:00 Twitch Note Added: 0027790
2015-03-20 17:38 cuteulala Note Added: 0027910
2015-03-21 00:16 Gavin Hird Note Added: 0027913
2015-03-21 00:41 dahlia Note Added: 0027914
2015-03-21 04:05 Twitch Note Added: 0027915
2015-03-21 08:08 OtakuMegane Note Added: 0027917
2015-03-21 13:40 cuteulala Note Added: 0027926
2015-03-26 18:45 kenvc Note Added: 0027945
2015-03-27 22:42 jozee tungsten Note Added: 0027950
2015-03-28 07:06 Robert Adams Note Added: 0027951
2015-04-28 09:35 jozee tungsten Note Added: 0028119
2015-04-28 13:32 Misterblue Note Added: 0028121
2015-05-03 22:35 Robert Adams Note Added: 0028174
2015-05-04 14:28 OtakuMegane Note Added: 0028197
2015-05-04 22:24 cuteulala Note Added: 0028207
2015-05-04 22:24 cuteulala Status new => resolved
2015-05-04 22:24 cuteulala Resolution open => fixed
2015-05-04 22:24 cuteulala Assigned To => cuteulala
2015-06-04 17:08 Robert Adams Status resolved => closed
2015-06-04 17:08 Robert Adams Assigned To cuteulala =>
2015-06-04 17:08 Robert Adams Fixed in Version => master (dev code)

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker