[Opensim-dev] Still on Sim and Phys Frames per Second (FPS)
Melanie
melanie at t-data.com
Sun Nov 8 02:34:38 UTC 2015
There are too many viewers in the wild, having too many users that
are unwilling to switch or update, yet complain about "lag" which
they do not perceive, but which is indicated by a "lag meter" that
is geared to measure against constants provided by "that grid".
It is a given that the data sent to viewers WILL be changed to allow
viewer features to work properly again. It is also a given that
control over this will be given to users of OpenSim, allowing them
to see true performance data instead of expected data. However, that
option can't be the default in a world where the primary use of
OpenSim is to provide a social virtual world.
I had already suggested and here suggest it again to add more data
to the stats reporting that will track accurate and unfudged data,
but doesn't do so in fields currently interpreted in accordance to
SL standards by ALL mainstream viewers.
This will allow viewers which become aware of the new data to use it
to provide accurate stats and, for instance, make an adaptive "lag
meter" in place of the current, constants driven one.
The situation where viewer report an ERROR CONDITION because of the
desire of some to see "accurate" stats can not be sustained because
it undermines user confidence.
The choices are to accede to user demands while creating a way for
viewers to get "smarter" or to live in a world where the change is
introduced at source code level by grid operators without an
adequate correct replacement stat, therefore locking in the current
situation forever.
Please understand that core exists to guide this project in a way
that allows it's users to work, not in a way that upholds principles
over people.
- Melanie
On 08/11/2015 02:53, dz wrote:
> 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> 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
>> > 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