|Anonymous | Login | Signup for a new account||2019-03-24 04:51 PDT|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0008404||opensim||[REGION] OpenSim Core||public||2018-11-07 09:21||2018-11-07 21:51|
|Platform||All||OS||Windows, Mac, Linux||OS Version||All|
|Target Version||Fixed in Version|
|Summary||0008404: ON-DEMAND priorities not set for best user experience|
|Description||Note: this discussion began in a texture-rezzing Mantis, but became so overwhelmingly important it seems wise to give it its own Mantis, as it covers far more than just textures.|
ISSUE: "On demand" events are not being given proper prioritization on the Opensim platform. This causes "lag" (where there is no actual system-caused lag), negative user experience, and conceptually people giving up on Opensim and leaving due to "poor performance.
In actuality... all that's happening is failure to give proper priority to on-demand services. (See Additional Notes for further explanation).
This is possibly THE greatest problem on Opensim at this time-- a system-wide logical bottleneck that affects the performance of every user, every day. Fix this... fix the metaverse. : )
|Additional Information||(Part of this is copied from Mantis 0008396)|
"ON DEMAND" events, defined: Functions that are directly triggered by user/avatar action, expecting and demanding immediate response because the user's attention is focused 100% on this event.
When an avatar is on a region and we tell it to walk forward, we are making an "on demand" request of the system. We expect the avatar to start walking immediately, not sometime in the distant future.
When we turn the avatar in a circle, we expect it to immediately start turning in a circle. If we tell it to fly, we expect it to immediately start flying. When we alt-click on an object to zoom in, we expect to zoom in now.
In all of these activities, we rightly expect immediate response from the system, all the way from the asset server to the region server to the viewer. We expect these things to occur NOW, not half a minute from now.
If we try to walk and that doesn't happen for 5, 10, 15 or more seconds, that is what we often label "lag"... the system not responding properly to "on demand" user activity.
This same concept holds true for user-triggered texture rezzing. When we click on a vendor, a photo display, edit a prim, zoom in close on a surface, double click a texture from inventory, or drag a texture from inventory to a prim... we are performing an "on demand" action. We rightfully expect immediate response from the server, namely... texture loading being given as much priority as walking. We expect that single texture to appear NOW, not 16 seconds from now. Yes, 2 or 3 seconds is acceptable. It does take *some* time. Longer than that however, and user frustration sets in.
That the system is not fully rezzing textures within reasonable time is the elusive "bottleneck" that is the core of this issue: simple failure to top-prioritize an on-demand avatar action.
Most of us can handle a texture rezzing in 2 to 3 seconds. 13 to 16 seconds... not so much. That adds up to a whole lot of wasted user time when rezzing multiple textures-- such as when trying to build, look at a photo viewer, or read several signs.
This concept applies to use of gestures and sounds. How many times have we tried to use a gesture, only to have it come through 30 seconds later? How often do we try to listen to a music player only to have it "lag" and skip music clips?
All of this is caused by lack of on-demand prioritization. This logical concept is affecting many process, grid-wide, metaverse-wide. If we balance on-demand prioritization-- if we give higher priority to on-demand actions-- we fix some of the oldest and most negative problems in the metaverse.
THE OTHER SIDE OF THE COIN-- giving too much prioritization: When an avatar logs in or out of a region, we are all aware that action can momentarily bring the entire region to a standstill. If one watches the screen of a region server we realize almost ALL of that server's processes are being dedicated to teleporting that avatar. The teleport is an "on demand" process... but far too great a priority is being given to that process.
Yes, teleporting is important and we want it to be accomplished as quickly as possible. (It would be nice to have the user informed on the viewer screen the progress of that teleport in greater detail so they know they haven't crashed during the process.)
However, while this is an on-demand process of high priority, it should not be so high that it brings all other activities on the region to a complete standstill. That needs to be throttled down a bit. Transferring an avatar to another region is a basic concept:
* A handshake between two servers, data transfer, verification of that data transfer, drop the handshake when transfer is complete and VERIFIED.
It should be a simple process and completed in steps, allowing other region functions to continue as normal. Currently it is being given such high priority it affects every avatar on the region, commonly bringing the entire region to a halt until the teleport is complete. Teleportation on-demand priority could use a bit of leveling.
On the other hand, texture rezzing (especially) should be given much higher priority. A texture should never take 16 seconds or more to rez (that is the current measured time of average single-texture rezzing). This affects user shopping experience, photo viewing experience, building experience-- wasting user time. Ultimately it can frustrate new users to the point they give up on Opensim and go find something else to do.
ON-DEMAND PRIORITIZATION is the primary bottleneck issue. This has become crystal clear after performing recent tests on multiple regions. Fix this... and the user experience on Opensim will improve tremendously.
|Tags||No tags attached.|
|Git Revision or version number|
|Run Mode||Grid (Multiple Regions per Sim)|
edited on: 2018-11-07 09:36
Addendum: please note the above observations are based on information available to a USER, along with information gathered from a visible region server. I'm not a dev and don't know the deep internal workings of Opensim. I am however a retired CEO, professional systems analyst / coder, and have 15+ years heavy experience with virtual worlds. So we can call the above "educated observations" and leave the wee details to those better informed in such things. : )
That said... I feel fairly confident the experiments, observations and conclusions in this are accurate. On-demand processes need balanced... and definitely on-demand texture rezzing given higher priority. "If the 2D don't work, the 3D don't work."
edited on: 2018-11-19 10:09
Follow-up addendum: there is a school of thought that the majority of this is a "viewer issue". While it is possible that the viewer is at least partially responsible for lack of on-demand prioritization, it would be a mistake to blame the viewer for the majority of this issue. The viewer has little to do with the teleportation process, yet that process is being given far too much prioritization (to the point it brings the entire region to a standstill). That's Opensim, not the viewer.
If the texture rezzing process is 100% a viewer issue, then yes the viewer is a major problem. However the question comes: what percentage of texture process is performed by the viewer... and what percentage performed by the region server?
When a user drags a texture to a prim to be surface-applied, the region server contacts the asset server, pulls in that texture, transfers the texture to the viewer, and the viewer displays that texture. The viewer cannot display what it has not yet fully received. Since the viewer can almost instantly rez a texture on an empty region, evidence strongly indicates the core function of texture fetching and providing it to the viewer comes from the region server. This would indicate an Opensim logic failure to top-prioritize on-demand texture loading.
On the other hand, when the texture is in the user's hard drive cache it would seem the viewer is almost 100% responsible for the retrieval of that texture. There is little doubt there are major cache problems in the Viewer system. However, those flaws do not seem to apply to a *single* texture being applied to a prim or viewed on the screen... especially in an instance where that texture is "fresh" (not in the viewer cache) and is being fetched via the region and asset servers.
Something in this process is performing a redundant demand-load from the asset server, fetching the same textures over and over again. This is literally creating an internal DDoS attack on Opensim's own asset servers. That is something that absolutely needs fixed. It does not however, account for excessive rezzing time of a single texture in a direct on-demand event.
Just a follow-up to discuss claims of viewer malfunction. While there are definitely viewer issues (and those issues need to be addressed and fixed), that does not eliminate the issues that are originating in Opensim itself. There ARE on-demand bottlenecks in the Opensim system that need correct prioritization, as described above.
To repeat: when a user calls up a single texture, the level of priority given to that on-demand event should be equal to walking or flying. The user's focus is 100% on that process-- thus that process should be given high priority. Given proper priority status, the texture should rez in 2-3 seconds (acceptable), not 13-16 seconds (unacceptable).
|2018-11-07 09:21||SnootsDwagon||New Issue|
|2018-11-07 09:32||SnootsDwagon||Note Added: 0033440|
|2018-11-07 09:35||SnootsDwagon||Note Edited: 0033440||View Revisions|
|2018-11-07 09:36||SnootsDwagon||Note Edited: 0033440||View Revisions|
|2018-11-07 09:48||Luisillo_Contepomi||Note Added: 0033441|
|2018-11-07 09:48||Luisillo_Contepomi||Note Edited: 0033441||View Revisions|
|2018-11-07 09:53||Luisillo_Contepomi||Note Edited: 0033441||View Revisions|
|2018-11-07 09:54||Luisillo_Contepomi||Note Deleted: 0033441|
|2018-11-07 10:21||UbitUmarov||Relationship added||related to 0008396|
|2018-11-07 21:51||SnootsDwagon||Note Added: 0033445|
|2018-11-07 21:52||SnootsDwagon||Note Edited: 0033445||View Revisions|
|2018-11-07 21:53||SnootsDwagon||Note Edited: 0033445||View Revisions|
|2018-11-07 21:54||SnootsDwagon||Note Edited: 0033445||View Revisions|
|2018-11-07 21:55||SnootsDwagon||Note Edited: 0033445||View Revisions|
|2018-11-07 21:56||SnootsDwagon||Note Edited: 0033445||View Revisions|
|2018-11-19 10:09||SnootsDwagon||Note Edited: 0033445||View Revisions|
|Copyright © 2000 - 2012 MantisBT Group|