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

Maxwell, Douglas CIV USARMY ARL (US) douglas.maxwell3.civ at mail.mil
Fri Apr 17 15:28:06 UTC 2015


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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5629 bytes
Desc: not available
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20150417/432e4755/attachment.bin>


More information about the Opensim-dev mailing list