[Opensim-dev] Open Simulator Metrics Reporting Changes (Phase 1) (UNCLASSIFIED)

Sat Apr 18 21:04:53 UTC 2015

Dahlia, sorry, i missed the ll function. The dilation as Sean defined makes sense to me, but i agree, the ll function shoul conform to ll "specs" or expectations. An os function would be a better place for the new value.

Sent from my iPad Air 2

> On Apr 18, 2015, at 4:27 PM, Dahlia Trimble <dahliatrimble at gmail.com> wrote:
> 
> Frank, sure, but deviations from the SL  behavior can be made in alternate APIs or protocols. Anything with the prefix "LL" or "ll" is meant to conform (as well as practical) to any observed and/or documented behaviors as implemented in SL. Unfortunately, deviation from such behavior is often the root cause of many bug reports and support issues. Users expect conformity in this regard. Given that the vast majority of the code base was donated by people in order to achieve this conformity, their actions should be respected. Indeed, if such conformity did not exist them MOSES would probably not have chosen to OpenSImulator in the first place.
> 
> Personally, I have objects which rely on proper angular velocity and which are coded in accordance with such specs. I'd be somewhat upset if those objects broke due to something breaking conformity to those specs.
> 
> 
>> On Sat, Apr 18, 2015 at 12:52 PM, Frank Nichols <j.frank.nichols at gmail.com> wrote:
>> My feeling is that at this point SL specs should be considered only as  a last resort, and whenever possible decisions should be made based on "improving" the design. Heavy consideration should be given when someone serious is willing do the research and work required to implement the improvements. 
>> 
>> Thank you Sean.
>> 
>> Sent from my iPad Air 2
>> 
>>> On Apr 18, 2015, at 1:58 PM, Dahlia Trimble <dahliatrimble at gmail.com> wrote:
>>> 
>>> According to http://wiki.secondlife.com/wiki/LlGetRegionTimeDilation 
>>> "Returns a float that is the current time dilation, the value range is [0.0, 1.0], 0.0 (full dilation) and 1.0 (no dilation)" showing the value returned as ranging trom 0 to 1, It's not clear from this document  if this is the same value that is passed to the viewer as a part of many UDP packets.
>>> 
>>> I would suggest if you need to change the definition to go beyond this range that you report it under a different name as an additional statistic. Another way might be to report it as traditionally understood and then add the additional factors to the statistics display which can be used to derive the value(s) you prefer.
>>> 
>>> 
>>>> On Sat, Apr 18, 2015 at 9:01 AM, Sean M <mondesire.sean at gmail.com> wrote:
>>>> Thanks for the feedback Dahlia, Kevin, and everyone else! I appreciate you taking the time to read our proposed changes and your comments.
>>>> 
>>>> The proposed set of metrics were all modified with the goal of reporting simulator performance at any moment in runtime. We did this by first gaining as much of an understanding of the OpenSim statistics reporting as possible and predicting the impact and overhead these changes would bring to the simulator's performance.
>>>> 
>>>> With that said, Time Dilation is the least documented and used metric by OpenSim in this set of measures. Originally, dilation was intended to measure simulation slow-down used to synchronize physics calculations with the effects observed in the viewer. OpenSim has moved away from this notion a while ago with the integration of BulletSim. Similarly, dilation is not explicitly used by XEngine. It is possible for someone to use the dilation in a script but with the value being a constant, I fail to see the practicality and utility.
>>>> 
>>>> If you monitor dilation in your regions, you will notice that dilation always reports a value of 1, regardless of fluctuations in actual physics frame time, simulator frame time, total frame time, or any of their rates. This constant value means that dilation cannot be used as a measure to gauge performance. 
>>>> 
>>>> Just to clarify, dilation is normally a measure of how long or wide something is. If we say "time dragged on", time dilation is larger than if "time flew by". Therefore, OpenSim's use of the word "dilation" can be a misnomer. Our proposed changes positively unbinds dilation; the new calculation ranges from [0:Infinity). The previously intended range of [0:1] artificially places a limit on how long the simulator has waited for physics; this limit is not accurate because, theoretically, a physics frame can take forever. With the new calculation, we want to measure simulator and physics frame time in respect to the minimum frame time (default is 89ms). Therefore, if dilation is at most 1, the simulator is performing very well. Anything greater than 1 and the simulator is exceeding the minimum frame time because it is struggling to process frames. Unbinding dilation allows one to know how poorly the simulator is performance without restriction.
>>>> 
>>>> In the viewer code, particularly in Phoenix Firestorm Viewer, Time Dilation is used for updating angular velocity calculations for idle objects. Dilation could be a part of the viewer to mitigate dead reckoning and rubber banding although I have not discovered any evidence for this after going through the sources of OpenSim and Firestorm.
>>>> 
>>>> Extensive testing was performed last week with the proposed metrics in place. Time Dilation was given focus because its calculation changes were different than its original intention. In the tests, abnormally high amounts of load (logged in, continuously moving avatars that used Firestorm) were placed on the simulator to determine avatar thresholds before the user experience degraded (rubber-banding, unresponsive viewers, simulation lag, etc). The user experience did not degrade until these abnormally high thresholds were reached. In other words, with the introduction of the new, upper unbounded dilation calculation, zero unusual actions took place from both the viewer and simulator standpoints. On the other hand, the new dilation measure proved to be a more accurate measure of the relationship between simulator performance and increased load than SimFPS.
>>>> 
>>>> If anyone has a deeper understanding of time dilation and its relationship with viewer synching than I, please feel free to point me to specific areas in either code-bases that maybe negatively affected by this new calculation. The last thing that we want to do is introduce bugs into the system. Also, I encourage anyone hosting a region to try the changes we are proposing and report back any findings. All of these metric changes are accessible through the OpenSim command-line "show stats".
>>>> 
>>>> Thanks everyone for your feedback!
>>>> 
>>>> Sean Mondesire, Ph.D.
>>>> MOSES Team
>>>> 
>>>>> On Sat, Apr 18, 2015 at 8:00 AM, Maxwell, Douglas CIV USARMY ARL (US) <douglas.maxwell3.civ at mail.mil> wrote:
>>>>> If current management and monitoring systems are relying on bad data, then it would be prudent to consider updating that software - not blocking the corrective measures on the server side.
>>>>> 
>>>>> We will complete internal testing by COB Monday and update the gitHub.  You can download our version of OS from there and perform your own tests.
>>>>> 
>>>>> Douglas Maxwell, MSME
>>>>> Science and Technology Manager
>>>>> Virtual World Strategic Applications
>>>>> U.S. Army Research Lab
>>>>> Human Research & Engineering Directorate
>>>>> Simulation & Training Technology Center
>>>>> (c) (407) 242-0209
>>>>> 
>>>>> ________________________________________
>>>>> From: opensim-dev-bounces at opensimulator.org [opensim-dev-bounces at opensimulator.org] on behalf of Kevin [kevin at ve3syb.ca]
>>>>> Sent: Friday, April 17, 2015 1:55 PM
>>>>> To: opensim-dev at opensimulator.org
>>>>> Subject: Re: [Opensim-dev] Open Simulator Metrics Reporting Changes (Phase 1) (UNCLASSIFIED)
>>>>> 
>>>>> On 2015-04-17 11:28, Maxwell, Douglas CIV USARMY ARL (US) wrote:
>>>>> > Time Dilation:
>>>>> > Previous:  Originally just returned the PhysicsScene value for
>>>>> > TimeDilation
>>>>> > which is 1.0.
>>>>> >
>>>>> > New:  The time it took for the physics and simulation to run not
>>>>> > including
>>>>> > the sleep time, divided by the minFrameTime passed into the program
>>>>> > from the
>>>>> > OpenSimDefaults.ini file variable MinFrameTime. This would mean that a
>>>>> > value
>>>>> > of 1 is no sleep necessary, less than 1 and the program slept for some
>>>>> > remaining amount of time, and greater than 1 the physics and simulation
>>>>> > took
>>>>> > longer to run than the allotted time.
>>>>> 
>>>>> The proposed changes to the stats seem reasonable to me until I got to
>>>>> Time Dilation. The way I read your proposal might alter the behaviour of
>>>>> some scripts or might affect, or possibly break, some external grid
>>>>> administration systems that use Time Dilation. The way I understand Time
>>>>> Dilation is that it varies from 0 to 1 and a number less than one is
>>>>> usually a sign of lag in the region. Your proposal seems to indicate
>>>>> that values can range from less than one to more than one with less than
>>>>> one being better than if TD is 1.
>>>>> 
>>>>> --
>>>>> 
>>>>> Cheers!
>>>>> 
>>>>> Kevin.
>>>>> 
>>>>> http://www.ve3syb.ca/           |"Nerds make the shiny things that
>>>>> distract
>>>>> Owner of Elecraft K2 #2172      | the mouth-breathers, and that's why
>>>>> we're
>>>>>                                  | powerful!"
>>>>> #include <disclaimer/favourite> |             --Chris Hardwick
>>>>> 
>>>>> _______________________________________________
>>>>> Opensim-dev mailing list
>>>>> Opensim-dev at opensimulator.org
>>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>>> _______________________________________________
>>>>> Opensim-dev mailing list
>>>>> Opensim-dev at opensimulator.org
>>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Opensim-dev mailing list
>>>> Opensim-dev at opensimulator.org
>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>> 
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at opensimulator.org
>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>> 
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at opensimulator.org
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20150418/29d9b13e/attachment.html>