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