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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> 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 <[email protected]> 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) >>>>> <[email protected]> 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: [email protected] >>>>> [[email protected]] on behalf of Kevin >>>>> [[email protected]] >>>>> Sent: Friday, April 17, 2015 1:55 PM >>>>> To: [email protected] >>>>> 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 >>>>> [email protected] >>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>>> _______________________________________________ >>>>> Opensim-dev mailing list >>>>> [email protected] >>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>> >>>> >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> [email protected] >>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> [email protected] >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> _______________________________________________ >> Opensim-dev mailing list >> [email protected] >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > _______________________________________________ > Opensim-dev mailing list > [email protected] > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________ Opensim-dev mailing list [email protected] http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
