These changes look very good to me, however, I would expect some people to be very upset. My understanding is that the numbers were “tweaked” to match what people were used to seeing in Secondlife.
I hope, we can move beyond SL at least on this issue and prefer accurate numbers instead of “tweaked to look like SL” numbers. Frank > On Apr 17, 2015, at 11:28 AM, Maxwell, Douglas CIV USARMY ARL (US) > <[email protected]> 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 > [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
