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

Fri Apr 17 20:06:55 UTC 2015

Hi Douglas,

At first glance, most of those look like useful changes that we should
consider accepting. I do have some concerns about the changes to time
dilation though. It's my (possibly incorrect) understanding that the time
dilation value is used to adjust the velocity of interpolated movement in
the viewers. A value of 1.0 (typically the maximum value) allows the avatar
or object to move at the velocity specified in the last ObjectUpdate
message for that entity. As time dilation decreases, that entity will move
proportionally slower. If I interpret your message correctly, with your new
implementation when the physics engine engine is running slower than normal
due to excessive load, time dilation will increase. This would seem to have
the opposite effect than desired; the affected entities would move faster
than normal rather than slower and possibly induce a lot of "rubber
banding". It would seem that if there is more time available than necessary
to process physics and some sleep is allowed, then time dilation should be
1.0 and only go below 1.0 when the physics scene must be slowed down to
accommodate inadequate physics processing time. This would apply to the
time dilation value that is sent with many of the UDP packets to viewers.
It may not need to apply to the value reported in the "show stats" command,
however then I think it should be renamed to something other than "time
dilation".

Regards,
-dahlia

On Fri, Apr 17, 2015 at 8:28 AM, Maxwell, Douglas CIV USARMY ARL (US) <
douglas.maxwell3.civ at mail.mil> wrote:

> Classification: UNCLASSIFIED
> Caveats: NONE
>
> Good Morning Everyone, I'd like to share with you a synopsis of a report
> prepared for me by Steven Zielinski and Sean Mondesire.  This is the result
> of the discussions held with the dev list last month regarding frame rate
> and sampling.  We are preparing to release a number of patches to the open
> simulator developers that will fix a number of inaccurate simulator
> statistics and data collection mechanisms we uncovered while profiling the
> code.  These changes are critical to the correct sampling of the
> simulator's
> behavior and will affect future development as we introduce new scaling
> (think DSG-after-next) and fidelity enhancements.
>
> The code fixes have been rolled into the MOSES and testing has been
> positive
> thus far.  Below is a brief discussion of each of the updates for your
> consideration and preparation for the coming patches.  Your constructive
> feedback is welcome.
>
> Sim FPS:
> Previous Metric/Definition:  This was the amount of frames being processed
> during a single second multiplied by a correction factor to make it look as
> though they were processing close to 60 frames per second.
>
> New Metric/Definition:  This is the amount of frames being processed during
> a single second. This is calculated by adding a single frame to a counter
> inside the StatsReporter, and then dividing by the time between statistics
> heartbeats.
>
> Physics FPS:
> Previous:  This was originally handled by the individual physics engines.
> There was a need for a change because there was no threading off of the
> physics engine. Each time the physics engine was updated the program would
> pause and wait for the calculations to complete. Looking into Bullet's
> calculation we found that there was an algorithm numSubSteps *
> m_fixedTimeStep * 1000 * NominalFrameRate. When looking at this further it
> was determined that numSubSteps was the minFrameTime / m_fixedTimeStep.
> Thus
> the above math becomes minFrameTime * 1000 * NominalFrameRate. This was
> then
> added to the SimStatsReporter where they divide by 1000. Which left us with
> minFrameTime * NominalFrameRate. This meant that every run through the
> update loop add .089 * 55 to the physics time value of SimStatsReporter.
> This equaled 4.895 so the number of frames times 4.895 resulted in the
> physics FPS for bullet.
>
> New:  This is now the amount of frames being processed during a single
> second. This is calculated by adding a single frame to a counter inside the
> StatsReporter, and then dividing by the time between statistics heartbeats.
> This matches the Sim FPS because they are currently running on the same
> thread and only a single frame of physics is updated when a single frame of
> the simulation is updated.
>
> Total Frame Time:
> Previous:  Here we needed to add a stopwatch instead of using the original
> EnvironmentTickCount. The reason for the change was that the
> EnvironmentTickCount only updates a few times a second while the stopwatch
> will get an exact time in milliseconds. This change was also done for the
> physics and simulation time. Also this used to only grab a single frame
> (including the sleep and statistics gathering) and display the result.  The
> single frame was changed on both the physics and simulation time as well.
>
> New:  This is now an average for the past N frames of the total time it
> took
> to complete a frame. Where N is the value given inside of the OpenSim.ini
> file by the variable NumberOfFrames inside of the Statistics section. This
> includes the time that opensim slept to match the current frame time.
>
> Physics Time:
> Previous:  Only had the changes listed in total frame time.
>
> New:  This is now an average for the past N frames of the total time it
> took
> to complete a physics update to the scene. Where N is the value given
> inside
> of the OpenSim.ini file by the variable NumberOfFrames inside of the
> Statistics section. This includes the time that opensim ran the
> preprocessing of physics and the physics update. If physics is disabled the
> time it took to check whether physics was disabled is used.
>
> Simulation Time:
> Previous: Changed the things listed in total frame time. Also changed that
> instead of calculating each section (tempOnRezMS, eventMS, backupMS,
> terrainMS, landMS) there were only two sections. The reason for two
> sections, the physics section separates parts of the simulation section.
> Each section that was originally included has remained the same.
>
> New:  This is now an average for the past N frames of the total time it
> took
> for the simulation to run. Where N is the value given inside of the
> OpenSim.ini file by the variable NumberOfFrames inside of the Statistics
> section. This does not include the time that physics was running or the
> time
> that open sim slept to match the current frame time.
>
> 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.
> ((simulationFrameTime+physicsFrameTime)/minFrameTime)  All times are based
> on a single frame and not averaged across multiple data points.
>
>
> v/r -doug
>
> Douglas Maxwell, MSME
> Science and Technology Manager
> Virtual World Strategic Applications
> U.S. Army Research Lab
> Simulation & Training Technology Center (STTC)
> (c) (407) 242-0209
>
>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
> _______________________________________________
> 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/20150417/d003c97f/attachment.html>