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

Sat Apr 18 16:01:11 UTC 2015

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20150418/1aad95a9/attachment.html>