+1 dz I cannot add to the well informed technical reasonings already contributed.
But, the suggested amendment is purely cosmetic. I fail to understand why grid operators are persistently unable to portray the importance of accurate measurements to their clients. Of equal concern is perpetuating a culture where non evidence based observations prevail within the user community only to be dismissed by equally subjective reasoning. +1 dz (again) Z On 9 November 2015 at 16:37, Maxwell, Douglas CIV USARMY RDECOM ARL (US) < [email protected]> wrote: > Classification: UNCLASSIFIED > Caveats: NONE > > +1 dz > > I'm not trying to start a flame war, so pls take these comments as my own > opinion. > > To be honest, I don't understand how the counter-argument to accurate > reporting could possibly be taken seriously. We have done some intense > troubleshooting on the OpenSimulator to try to find where instabilities and > performance enhancements can make most sense. Pandering to the users by > artificially inflating the numbers does no one any good and is quite > frankly, > weak sauce. I'm sorry the lag meters don't work anymore, but that is the > consequence of improperly reporting the stats in the first place. The > correct > fix here isn't to re-break stats reporting. > > Secondly, I don't understand how the Devs plan(!) to address the three > major > components of the CORE that need work to improve stability and scalability. > We (MOSES) are testing the new PhysX addition and could not do our jobs > without proper stats reporting. In fact, months of work (and money) was > wasted > last year when we attempted to address physics issues and profiling only to > find out we couldn't trust the data we were collecting! > > Our next work will involve addressing the client manager issues and will > hopefully yield a workable architecture to allow dozens of people to log in > simultaneously without lag or impact on the rest of the simulator. Again, > can't do this without proper stats reporting. > > Think of this as a MacOSX moment. Might break some old things, but in the > end > you will be better for it. > > v/r -doug > > Douglas Maxwell, Ph.D. > Science and Technology Manager > Virtual World Strategic Applications > U.S. Army Research Lab > Simulation & Training Technology Center (STTC) > (c) (407) 242-0209 > > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of dz > Sent: Saturday, November 07, 2015 8:54 PM > To: [email protected] > Subject: [Non-DoD Source] Re: [Opensim-dev] Still on Sim and Phys Frames > per > Second (FPS) > > All active links contained in this email were disabled. Please verify the > identity of the sender, and confirm the authenticity of all links contained > within the message prior to copying and pasting the address to a Web > browser. > > > ________________________________ > > > > The issue is promoting accurate reporting of basic performance measurement > statistics. ( something that has not achieved nearly enough serious > attention ) > > Significant money and manpower is currently being directed at efforts to > improve simulator performance. > It is a simple fact that the continued funding of these efforts relies on > documenting the ACTUAL improvement against the ACTUAL original > performance > characteristics. > It is impossible to justify these efforts when the reported numbers are > "made up" and THAT fact is not documented except in some obscure comment > left behind in the source code. > > > It is unfortunate that the original decision to include a "Fudge factor > multiplier" has created a pool of mis-informed users ( including myself > and > the viewer developers ) . > This mistake was complicated by the fact that until very recently there > was a > philosophical divide that prevented OpenSim and viewer developers from > cooperating on issues like these. > This decision to "play pretend" with performance stats effectively damaged > the > reporting credibility of everyone who published these inaccurate > results, > It also created a rift between the OpenSim and viewer developers over the > decision to NOT discuss the impact of implementing the change. The > fact > is, there are numerous places in the OpenSim framework where numbers > are > "made up" just so that a number appears in performance reports. That an > effort is being made to correct those sources of mis-information should > be > welcomed. > > > It seems to me that the decisions made by core should be made in favor of > supporting the ongoing efforts to accurately document and improve > simulator > performance. > Justin realized this and lead many of the efforts to add some measurement > metrics. Even with those efforts, we still cannot measure basic > statistics like Events per Second sent to the script engine, or tie those > events to whatever script is handling them. This makes identifying the > scripts ACTUALLY responsible for "lagging" a region impossible using the > traditional TOP SCRIPTS report in region manager window. > > I would agree that a simple solution might be to allow grid managers to > add > back the Fudge Factor to appease their vocal users, but would disagree > that > the PROPER decision should be to continue to report inaccurate results. > It > would be just as easy to implement a multiplier in the viewer code "Lag > Meter", This would also allow the accurate reporting of statistics in > the > Advanced Statistics window and administrative reporting. I believe it > was > also one of the suggested resolutions put forth by the viewer > developers... It > should be clear to anyone who has spent time in world that the "lag > meter" is > incorrect... You can walk, build, chat and TP with the same level of sim > performance as you could before the numbers were changed. We've > overlooked > the fact that viewers have behaved differently in OpenSim and "that > other > grid" for years. Why is it "all of a sudden" CRITICAL that this one > viewer feature HAS to be the same? In these days when core developers > are releasing viewers, I cannot understand the urgency of accommodating a > minor feature of one viewer whose developers have already demonstrated a > willingness to work with OpenSim to tailor a configuration to meet our > needs. > > > > On Sat, Nov 7, 2015 at 1:19 PM, Melanie <[email protected] < > Caution-mailto:[email protected] > > wrote: > > > The issue here is the so-called "lag meter". Since removal of the > multiplier, this reports all opensim regions as laggy, without > exception. Users' trust in the "lag meter" is damaging OpenSim > reputation. This is not a value that is merely for display; the > viewer uses this value for computations that are then used to > "judge" a sim to be "laggy" if it's below 35 or so fps. OpenSim now > always reports a lesser value. This is damaging and needs to be > made > configurable and by default match the viewer's expectations. > > - Melanie > > > On 07/11/2015 16:38, Seth Nygard wrote: > > While I understand the arguments surrounding the original > decision to > > report values closely matching "the other grid", IMHO doing so > created > > an incorrect understanding in many users' minds of how things > work > > and/or behave. We are not that other grid and should never > pretend to > > be. Had figures been reported correctly in the beginning then > there > > would be no confusion now surrounding this subject. However > avoiding > > confusion is a poor reason to roll back and once again report the > > artificially inflated values. It is better to simply educate > and make > > it clear that the value of 11fps is indeed the correct value to > expect, > > and is in fact the true value things always have ran at despite > what any > > inflated reported value said. > > > > It is true that many scripts and tools have already been written > to use > > the inflated values but they can all be changed with relative > ease. The > > viewers already have many aspects that are different for Open > Simulator > > so they can be changed easily as well for new versions also with > > relative ease. All we need to do as a community is establish > what the > > correct and expected values are and then document and > communicate them. > > > > As a user, scripter, tool developer, and grid manager, I for one > want to > > see true and accurate values for any and all metrics regardless > of where > > they are shown or how they may be used. I therefore am firmly > against > > rolling back to any older artificially inflated values. > > > > Regards > > -Seth > > > > > > _______________________________________________ > > Opensim-dev mailing list > > [email protected] < > Caution-mailto:[email protected] > > > Caution- > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev < > Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > > _______________________________________________ > Opensim-dev mailing list > [email protected] < Caution-mailto: > [email protected] > > > Caution- > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev < > Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > > > > > 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
