<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>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. </div><div><br></div><div>Thank you Sean.<br><br>Sent from my iPad Air 2</div><div><br>On Apr 18, 2015, at 1:58 PM, Dahlia Trimble <<a href="mailto:dahliatrimble@gmail.com">dahliatrimble@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div>According to <a href="http://wiki.secondlife.com/wiki/LlGetRegionTimeDilation">http://wiki.secondlife.com/wiki/LlGetRegionTimeDilation</a> <br>"Returns a float that is the current time dilation, the value range is <span title="0.0 ≤ time dilation ≤ 1.0" style="border-bottom:1px dotted">[0.0, 1.0]</span>, 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.<br><br></div><div>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.<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Apr 18, 2015 at 9:01 AM, Sean M <span dir="ltr"><<a href="mailto:mondesire.sean@gmail.com" target="_blank">mondesire.sean@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div>Thanks for the feedback Dahlia, Kevin, and everyone else! I appreciate you taking the time to read our proposed changes and your comments.<br><br>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.<br><br></div>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.<br><br>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. <br><br>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.<br><br></div>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.<br><br></div>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.<br><br></div>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".<br><br></div>Thanks everyone for your feedback!<br><br></div>Sean Mondesire, Ph.D.<br></div>MOSES Team<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Apr 18, 2015 at 8:00 AM, Maxwell, Douglas CIV USARMY ARL (US) <span dir="ltr"><<a href="mailto:douglas.maxwell3.civ@mail.mil" target="_blank">douglas.maxwell3.civ@mail.mil</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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.<br>
<span><br>
Douglas Maxwell, MSME<br>
Science and Technology Manager<br>
Virtual World Strategic Applications<br>
U.S. Army Research Lab<br>
</span>Human Research & Engineering Directorate<br>
<span>Simulation & Training Technology Center<br>
</span>(c) <a href="tel:%28407%29%20242-0209" value="+14072420209" target="_blank">(407) 242-0209</a><br>
<br>
________________________________________<br>
From: <a href="mailto:opensim-dev-bounces@opensimulator.org" target="_blank">opensim-dev-bounces@opensimulator.org</a> [<a href="mailto:opensim-dev-bounces@opensimulator.org" target="_blank">opensim-dev-bounces@opensimulator.org</a>] on behalf of Kevin [<a href="mailto:kevin@ve3syb.ca" target="_blank">kevin@ve3syb.ca</a>]<br>
Sent: Friday, April 17, 2015 1:55 PM<br>
To: <a href="mailto:opensim-dev@opensimulator.org" target="_blank">opensim-dev@opensimulator.org</a><br>
Subject: Re: [Opensim-dev] Open Simulator Metrics Reporting Changes (Phase 1) (UNCLASSIFIED)<br>
<div><div><br>
On 2015-04-17 11:28, Maxwell, Douglas CIV USARMY ARL (US) wrote:<br>
> Time Dilation:<br>
> Previous: Originally just returned the PhysicsScene value for<br>
> TimeDilation<br>
> which is 1.0.<br>
><br>
> New: The time it took for the physics and simulation to run not<br>
> including<br>
> the sleep time, divided by the minFrameTime passed into the program<br>
> from the<br>
> OpenSimDefaults.ini file variable MinFrameTime. This would mean that a<br>
> value<br>
> of 1 is no sleep necessary, less than 1 and the program slept for some<br>
> remaining amount of time, and greater than 1 the physics and simulation<br>
> took<br>
> longer to run than the allotted time.<br>
<br>
The proposed changes to the stats seem reasonable to me until I got to<br>
Time Dilation. The way I read your proposal might alter the behaviour of<br>
some scripts or might affect, or possibly break, some external grid<br>
administration systems that use Time Dilation. The way I understand Time<br>
Dilation is that it varies from 0 to 1 and a number less than one is<br>
usually a sign of lag in the region. Your proposal seems to indicate<br>
that values can range from less than one to more than one with less than<br>
one being better than if TD is 1.<br>
<br>
--<br>
<br>
Cheers!<br>
<br>
Kevin.<br>
<br>
<a href="http://www.ve3syb.ca/" target="_blank">http://www.ve3syb.ca/</a> |"Nerds make the shiny things that<br>
distract<br>
Owner of Elecraft K2 #2172 | the mouth-breathers, and that's why<br>
we're<br>
| powerful!"<br>
#include <disclaimer/favourite> | --Chris Hardwick<br>
<br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@opensimulator.org" target="_blank">Opensim-dev@opensimulator.org</a><br>
<a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@opensimulator.org" target="_blank">Opensim-dev@opensimulator.org</a><br>
<a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
<a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
<br></blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Opensim-dev mailing list</span><br><span><a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a></span><br><span><a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a></span><br></div></blockquote></body></html>