[Opensim-dev] [Non-DoD Source] Re: Still on Sim and Phys Frames per Second (FPS) (UNCLASSIFIED)
Melanie
melanie at t-data.com
Mon Nov 9 18:08:00 UTC 2015
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" <melanie at t-data.com
>> <mailto:melanie at t-data.com>> 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) <douglas.maxwell3.civ at mail.mil
>> <mailto:douglas.maxwell3.civ at mail.mil>
>> >> <mailto:douglas.maxwell3.civ at mail.mil
>> <mailto:douglas.maxwell3.civ at mail.mil>>> 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: opensim-dev-bounces at opensimulator.org
>> <mailto:opensim-dev-bounces at opensimulator.org>
>> >> <mailto:opensim-dev-bounces at opensimulator.org
>> <mailto:opensim-dev-bounces at opensimulator.org>>
>> >> [mailto:opensim-dev-bounces at opensimulator.org
>> <mailto:opensim-dev-bounces at opensimulator.org>
>> >> <mailto:opensim-dev-bounces at opensimulator.org
>> <mailto:opensim-dev-bounces at opensimulator.org>>] On Behalf Of dz
>> >> Sent: Saturday, November 07, 2015 8:54 PM
>> >> To: opensim-dev at opensimulator.org
>> <mailto:opensim-dev at opensimulator.org>
>> >> <mailto:opensim-dev at opensimulator.org
>> <mailto:opensim-dev at opensimulator.org>>
>> >> 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 <melanie at t-data.com
>> <mailto:melanie at t-data.com>
>> >> <mailto:melanie at t-data.com <mailto:melanie at t-data.com>> <
>> >> Caution-mailto:melanie at t-data.com
>> <mailto:melanie at t-data.com> <mailto:melanie at t-data.com
>> <mailto:melanie at t-data.com>> > >
>> >> 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
>> >> > Opensim-dev at opensimulator.org
>> <mailto:Opensim-dev at opensimulator.org>
>> >> <mailto:Opensim-dev at opensimulator.org
>> <mailto:Opensim-dev at opensimulator.org>> <
>> >> Caution-mailto:Opensim-dev at opensimulator.org
>> <mailto:Opensim-dev at opensimulator.org>
>> >> <mailto:Opensim-dev at opensimulator.org
>> <mailto:Opensim-dev at opensimulator.org>> >
>> >> >
>> >>
>> Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>> >> <
>> >>
>> Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>> >> >
>> >>
>> >> _______________________________________________
>> >> Opensim-dev mailing list
>> >> Opensim-dev at opensimulator.org
>> <mailto:Opensim-dev at opensimulator.org>
>> >> <mailto:Opensim-dev at opensimulator.org
>> <mailto:Opensim-dev at opensimulator.org>> <
>> >> Caution-mailto:Opensim-dev at opensimulator.org
>> <mailto:Opensim-dev at opensimulator.org>
>> >> <mailto:Opensim-dev at opensimulator.org
>> <mailto:Opensim-dev at opensimulator.org>>
>> >> >
>> >>
>> >>
>> 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
>> >> Opensim-dev at opensimulator.org
>> <mailto:Opensim-dev at opensimulator.org>
>> <mailto:Opensim-dev at opensimulator.org
>> <mailto:Opensim-dev at opensimulator.org>>
>> >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> Opensim-dev mailing list
>> >> Opensim-dev at opensimulator.org
>> <mailto:Opensim-dev at opensimulator.org>
>> >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Opensim-dev mailing list
>> > Opensim-dev at opensimulator.org <mailto:Opensim-dev at opensimulator.org>
>> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at opensimulator.org <mailto:Opensim-dev at opensimulator.org>
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
>>
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at opensimulator.org
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
More information about the Opensim-dev
mailing list