[Opensim-dev] Simulator Statistics Testing, Planning for Patches, Next Steps

Sun Apr 26 11:28:28 UTC 2015

Good Morning All,  in previous email I described the simulator statistics reporting adjustments we have been working on.  This group requested that we avoid sending a major code drop, so we have staggered the code updates into three different stats patches.  You could call the first patch a dry run of sorts to allow us to ensure proper formatting and integration on your side.  Looks like all we need to do is sort out the white spaces issue in the patch and we will be good to go.

For your planning purposes, here is the roadmap for all three stats patches:

Patch 1: Simulator FPS, Physics FPS, Total Frame Time, Physics Frame Time, and Simulation Time.

Patch 2: correct the broken user login freezes, XEngine Thread Count, Util Thread Count, System Thread Count, Proc Mem, Frame Dilation (previous the proposed Time Dilation).

Patch 3: network reporting:  UDPIn, UDPOut, UDPInError, PktsIn, PktsOut, Avatar to IP list, Server-to-Client Ping, and Average Server Ping (External).

The attached screenshot shows Patch 1 in action on the MOSES grid.  Based on your feedback, we did not affect how the script engine reports Time Dilation, however the simulator frame rate is reported accurately.  This is demonstrated via a scripted object (green box).  The statistics window reports Time Dilation accurately and is a constantly changing value based on simulator load, specifically physics interactions.  (Forgive the low client frame rate, I took the screenshot on an older laptop.)  Some of you have seen this screenshot, I'm providing it again for context.

What's next?  Physics & Networking.  Just tossing physical balls into a pit or logging in a few dozen bots isn't an adequate test.  There are too many variables at play and even simulator<->physics engine integration code is wickedly complex.  We need to be able to rely on the reporting of the simulator's behavior so we can know what adjustments are meaningful.  We don't yet know if PhysX is better than Bullet, but thorough and accurate testing is the only way to find out.

What's the potential payoff for you?  Imagine being able to hold an event like the OSCC in a single large var region.  Imagine having lots of people being able to log into a region simultaneously, rather than in serial like today.  Wouldn't it be nice to be able to actually plan for what hardware and network support you need for a grid, rather than just guessing and buying the best you can afford - not what you actually need?

This is what we are working towards.  If we can agree that these changes are valid and necessary, then I invite you to inspect our work.  If you object to the way we have implemented the changes, then we welcome feedback and will work with you to find a more compatible path.

In approximately 9 months, we will begin testing some new simulation based training material that involves large numbers of people and I would like to have a version of MOSES ready in time to support.  My only alternative is to continue licensing a very expensive proprietary engine.  It is my desire to cancel that license and devote those funds to open simulator development, but only if the MOSES can handle the work.

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<tel:%28407%29%20242-0209>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20150426/e7cc68fc/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ABWIS MOSES Prerelease_001.jpg
Type: image/jpeg
Size: 171801 bytes
Desc: ABWIS MOSES Prerelease_001.jpg
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20150426/e7cc68fc/attachment-0001.jpg>