I have heard this point brought up a few times and we concur. As it turns out, the statistics we collected during the joint ARL/Intel DSG events (all 6 of them) are now in question. We published results from those events in multiple conferences. Further, I am devoting a significant amount of engineering labor hours to a team that currently includes 6 computer scientists, two of which have PhD's. The realization that we had been testing and sampling the open simulator for physics and scalability on bogus simulator data was shocking.
Folks, you may not realize this but knowingly propagating the erroneous code is intellectually dishonest and has already wasted precious research funding. That we are even debating whether or not to fix the simulator reporting mechanisms is disturbing. What we should be debating is "how". The MOSES project has provided a solution that works for us and we need your knowledgeable feedback as core code experts to know if our solution is feasible for the community. 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> ________________________________ From: [email protected] [[email protected]] on behalf of Diva Canto [[email protected]] Sent: Saturday, April 25, 2015 2:05 PM To: [email protected] Subject: Re: [Opensim-dev] MOSES patch submitted (UNCLASSIFIED) I would like to hear from people who have either monitoring tools or bots that rely on the incorrect physics FPS. If these people exist, let's hear what pain it would cause them to correct the number. Otherwise, I don't see any reason to continue to report an incorrect number, and I see many reasons for fixing it: several PhD students have now either wasted a lot of their time or even made wrong data analysis because of this. On 4/24/2015 9:08 PM, Michael Emory Cerquoni wrote: It is more than just bots that worry me, many people have written custom monitoring tools to monitor region performance to automatically restart regions, not to mention script that could potentially rely on osGetRegionStats > http://opensimulator.org/wiki/OsGetRegionStats<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx> we could be potentially breaking all of this content if we are talking about long term leaving the statistics at these lower numbers, if we are talking about eventually having them resume to the normal levels etc.. that is something else, and if that is the case I would suggest we start a new branch for that work that would eventually merge into master once the work was complete. Like i said I am not against doing this work, but not at the expense of causing mass chaos amongst important users and testers of this software, how can we say we are improving the software if we are rushing into breaking stuff people may be very reliant on. On Sat, Apr 25, 2015 at 12:01 AM, Diva Canto <[email protected]<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx>> wrote: I'm +1 on the changes. I find it very unsettling to be shown a physics fps that is incorrect, and some of my students have been very confused about it in the past. I don't think the changes will affect bots in any significant way, but if someone can point me to a bot that will be affected, I would like to know. On 4/24/2015 6:23 PM, Dahlia Trimble wrote: I like the idea of a multiplier for physics fps, however I see no need for altering the value. If a reported number is linearly scaled, then any change in that number is also scaled proportionally. For example, if I have 55 fps reported for a real fps of 11 due to a scale factor of 5, all I need to do is divide by 5 to get the 11 back. If the 55 decreases by 10%, the 11 will also decrease by 10%. It really shouldn't matter as either value will provide the same indication of change in performance. As far as SL compatibility goes, I usually see a physics fps of 45 for a well running region in SL, not 55. In that case if such compatibility was desired, the factor would be 45/11 or approximately 4.1 rather than 5. On Fri, Apr 24, 2015 at 6:06 PM, Michael Emory Cerquoni <[email protected]<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx>> wrote: Also sounds like a reasonable solution as well, If the goal is to improve performance in general I am not sure it matters what is actually reported to the viewer , since i would assume any kind of real analysis would be done on the back end and not via the viewer #'s On Fri, Apr 24, 2015 at 9:04 PM, Mike Chase <[email protected]<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx>> wrote: Why not just introduce a new counter and function to fetch the value. The current one can always return the SL adjusted value. Mike On 04/24/2015 08:59 PM, Michael Emory Cerquoni wrote: What do you think about making the multiplier a modifiable variable in OpenSim.ini? This will allow anyone who wants to improve performance and use the stock #'s and in the meantime people can continue to use the code in a meaningful way without having to rewrite scripts and monitoring tools to continue testing other code that may be pushed into core, especially if the end goal is to get statistics to report back at the original numbers? I am mostly just trying to understand the end goal myself. If that is not possible I would suggest this work be moved into a development branch until we can get statistics back to the normal numbers again? Otherwise we are talking about locking the code down to all other development until this process is complete, and no one has discussed any kind of time frame for this level of changes to complete, I would hate to put a complete halt to development in order for this to happen. I am not against doing what you suggest, I just want to make sure we do it in the most efficient way possible. Would be good to hear what others in the core development have to say, hopefully Justin and Diva and Melanie, Misterblue, BlueWall, you guys can chime in here as well, as I am only one person here and for the record just voicing my own concerns, I am far from the final say on any of this stuff. On Fri, Apr 24, 2015 at 8:33 PM, Maxwell, Douglas CIV USARMY ARL (US) <[email protected]<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx>> wrote: Folks, before we can make any meaningful progress in performance enhancements to the open simulator we have to be able to rely on the simulator statistics. Currently they are (purposefully) misreported to make the simulator look like it is performing better than it really is. This is not acceptable if we are to dig in and begin to assist. 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<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx> ________________________________________ From: [email protected]<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx> [[email protected]<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx>] on behalf of Melanie [[email protected]<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx>] Sent: Friday, April 24, 2015 5:56 PM To: [email protected]<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx> Subject: Re: [Opensim-dev] MOSES patch submitted (UNCLASSIFIED) It is also my opinion that this change isn't fit for core. If and when additional stats, like "real fps" and "physics engine fps" can be shown in the viewer, then that would be good but the viewer stats window should continue to show the fudged figures indefinitely. This is because people don't only use scripts but also bots to do monitoring and bots receive the same data the viewer receives. - Melanie On 24/04/2015 23:42, Michael Emory Cerquoni wrote: > ok so just so I understand we should now see this actually just display > 11fps? Personally I think this is a bad idea, alot of people may be using > monitoring apps and scripts that look for low fps and restart the region, > we would basically be forcing everyone to rewrite a lot of code to > accommodate a singular purpose? Not quite sure how this improves the > project as a whole. > > On Fri, Apr 24, 2015 at 5:40 PM, Michael Emory Cerquoni < > [email protected]<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx>> > wrote: > >> ok I will continue testing this for now, we should try to resolve the >> white space issues before it hits core, we can worry about that later >> though. I hope others can start testing this patch as well we need to >> really make sure this does not break any scripts or monitoring apps before >> this changes the core code, so anyone who has the time please do test this >> and let us know if you notice anything change or break, thanks! >> >> On Fri, Apr 24, 2015 at 3:38 PM, Maxwell, Douglas CIV USARMY ARL (US) < >> [email protected]<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx>> >> wrote: >> >>> Classification: UNCLASSIFIED >>> Caveats: NONE >>> >>> What you saw were just warnings about white spaces. The patch should >>> still >>> apply and work. We follows the open simulator patch creation guidance >>> explicitly, if you guys have updated instructions for how you want this >>> done - >>> let us know. Otherwise, you can ignore the warnings. >>> >>> v/r -douglas >>> >>> 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<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx> >>> >>> >>> >>> -----Original Message----- >>> From: >>> [email protected]<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx> >>> [mailto:[email protected]<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx>] >>> On Behalf Of Michael Emory >>> Cerquoni >>> Sent: Friday, April 24, 2015 2:38 PM >>> To: >>> [email protected]<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx> >>> Subject: Re: [Opensim-dev] MOSES patch submitted >>> >>> please check the mantis, i had some trouble applying patch for testing, >>> thanks >>> guys! >>> >>> >>> On Fri, Apr 24, 2015 at 1:30 PM, Michael Heilmann >>> <[email protected]<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx>> >>> wrote: >>> >>> >>> Opensim Devs >>> >>> Just an FYI, mantis bug #7540 is the first code submission from >>> project >>> MOSES. Thanks. >>> >>> -- >>> Michael Heilmann >>> Research Associate >>> Institute for Simulation and Training >>> University of Central Florida >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> >>> [email protected]<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx> >>> >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx> >>> <blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx>> >>> >>> >>> >>> >>> >>> -- >>> >>> Michael Emory Cerquoni >>> >>> Classification: UNCLASSIFIED >>> Caveats: NONE >>> >>> >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> [email protected]<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx> >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx> >>> >>> >> >> >> -- >> Michael Emory Cerquoni >> > > > > > > _______________________________________________ > Opensim-dev mailing list > [email protected]<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx> _______________________________________________ Opensim-dev mailing list [email protected]<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx> _______________________________________________ Opensim-dev mailing list [email protected]<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx> -- Michael Emory Cerquoni _______________________________________________ Opensim-dev mailing list [email protected]<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx> _______________________________________________ Opensim-dev mailing list [email protected]<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx> -- Michael Emory Cerquoni _______________________________________________ Opensim-dev mailing list [email protected]<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx> _______________________________________________ Opensim-dev mailing list [email protected]<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx> _______________________________________________ Opensim-dev mailing list [email protected]<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx> -- Michael Emory Cerquoni _______________________________________________ Opensim-dev mailing list [email protected]<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev<https://web-mont05.mail.mil/owa/UrlBlockedError.aspx>
_______________________________________________ Opensim-dev mailing list [email protected] http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
