It would seem to me that correctness should be driving principle and not the size of the group that may need to make some effort.
Glenn Note: Sent from my cell phone. The opinions and thoughts in this email are my own and do not reflect those of any other person or organization. > On Nov 9, 2015, at 1:08 PM, Melanie <[email protected]> wrote: > > What we as core need to consider is that here the needs of the few > people doing research cannot outweigh the needs of the many who want > the viewer to function as expected. Therefore the minority who want > to do research should be the ones who change a setting, not the > majority interested in a working lag meter. > > I have made several suggestions how it may be possinle to transit > gracefully and without breaking things; alas, they were all ignored > in favor of principle thumping. > > - Melanie > >> On 09/11/2015 19:00, Terry Ford wrote: >> I think for sake of accuracy we should leave it by default to report >> correctly. >> For those who do not want the accurate results and prefer to use the >> multiplied values, give them an option in the ini file to set >> StatsFudgeFactorOn = true or something similar. >> Doing this would satisfy both sides without any further discussion and >> would then allow the grid/region operator the option to run it they way >> they prefer as it should be. >> >> ~Terry >> >>> On 11/9/2015 12:52 PM, Michael Emory Cerquoni wrote: >>> >>> Personally i think we should have left the fudge factor stats alone >>> and introduced new non multiplied stats. Forcing everyone to change >>> because one single project has a goal is not great. If the projects >>> goal is to do back end analysis who cares what we send to the viewer. >>> >>> On Nov 9, 2015 9:48 AM, "Melanie" <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Viewers WILL have to change but something like the "Lag Meter" does >>> depend on some way of generating a normalized value. >>> >>> This can either be done by normalizing to a standard frame of >>> reference, most often 0.0 .. 1.0 is used for this, or normalizing to >>> a known value, e.g. 55 fps. >>> >>> In the absence of a normalized value, viewers would not be able to >>> calculate the lag meter unless the stats packet also contains a >>> value telling the viewer what "normal" is. This is currently not the >>> case. >>> >>> With sim stats being a UDP packet, we really can't add fields easily >>> without breaking with the SL standard and all viewers strive to not >>> only work in OpenSim but also in SL. >>> >>> One could possibly add the "normal" value to the SimulatorFeatures >>> cap, since it is not expected that that value would or could change >>> while clients are logged in. That still would require viewers to >>> change and viewers are slow to change. >>> >>> Sadly, things required only by OpenSim are incorporated much less >>> speedily than things required for continued SL compatibility. We >>> should therefore strive to provide what is needed for the viewers to >>> adapt but some of us are not in a position to leave the current >>> users out in the rain. >>> >>> - Melanie >>> >>>> On 09/11/2015 18:40, Terry Ford wrote: >>>> DigiWorldz and Great Canadian Grid are running the newer code >>> with stats >>>> reporting 11fps without issue. >>>> When we first made the change, we let everyone know and we've >>> never yet >>>> had any complaints about it. >>>> I've not seen any issues regarding the change on my end so far. >>>> >>>> I personally prefer the corrected stats and I think as long as >>> everyone >>>> is made aware of the changes and the reasons, I don't think >>> there would >>>> be any issues. >>>> >>>> I am a fan of the Architect Frank Lloyd Wright and I remember >>> reading a >>>> story about him once... >>>> Someone had complained to him that his design on one of his >>> builds was >>>> very poor and it was leaking water each time it rained... his >>> reply... >>>> grab a bucket and catch the water. >>>> While his build looked awesome, it had an obvious flaw, but >>> instead of >>>> addressing it, he indicated using a bucket to catch the water >>> would fix >>>> the issue. >>>> Isn't that what we are essentially doing here... grabbing buckets? >>>> I personally prefer a roof which doesn't leak. >>>> >>>> ~Terry >>>> >>>> >>>> >>>>> On 11/9/2015 12:31 PM, Zadark Portal wrote: >>>>> +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] >>> <mailto:[email protected]> >>>>> <mailto:[email protected] >>> <mailto:[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 <tel:%28407%29%20242-0209> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: [email protected] >>> <mailto:[email protected]> >>>>> <mailto:[email protected] >>> <mailto:[email protected]>> >>>>> [mailto:[email protected] >>> <mailto:[email protected]> >>>>> <mailto:[email protected] >>> <mailto:[email protected]>>] On Behalf Of dz >>>>> Sent: Saturday, November 07, 2015 8:54 PM >>>>> To: [email protected] >>> <mailto:[email protected]> >>>>> <mailto:[email protected] >>> <mailto:[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] >>> <mailto:[email protected]> >>>>> <mailto:[email protected] <mailto:[email protected]>> < >>>>> Caution-mailto:[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <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] >>> <mailto:[email protected]> >>>>> <mailto:[email protected] >>> <mailto:[email protected]>> < >>>>> Caution-mailto:[email protected] >>> <mailto:[email protected]> >>>>> <mailto:[email protected] >>> <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] >>> <mailto:[email protected]> >>>>> <mailto:[email protected] >>> <mailto:[email protected]>> < >>>>> Caution-mailto:[email protected] >>> <mailto:[email protected]> >>>>> <mailto:[email protected] >>> <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] >>> <mailto:[email protected]> >>> <mailto:[email protected] >>> <mailto:[email protected]>> >>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Opensim-dev mailing list >>>>> [email protected] >>> <mailto:[email protected]> >>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> [email protected] <mailto:[email protected]> >>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>> _______________________________________________ >>> Opensim-dev mailing list >>> [email protected] <mailto:[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 >> >> >> >> >> _______________________________________________ >> 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 _______________________________________________ Opensim-dev mailing list [email protected] http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
