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]> 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]>> 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]>] On Behalf Of dz > >> Sent: Saturday, November 07, 2015 8:54 PM > >> To: [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]> < > >> Caution-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]> < > >> Caution-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]> < > >> Caution-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] > > > >> 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
