[Opensim-dev] Still on Sim and Phys Frames per Second (FPS)

AJLDuarte ajlduarte at sapo.pt
Sun Nov 8 04:55:24 UTC 2015


The fudge factor is now a configuration option on the avinationmerge branch.
It can be found in OpenSimDefaults.ini under the name StatisticsFPSfactor,
and can be set in OpenSim.ini as usual.
Its default in code is the legacy value of 5.0.
Current setting on file is temporary 1.0, until we decide on a "final"
default.

Regards,
Ubit



-----Original Message-----
From: opensim-dev-bounces at opensimulator.org
[mailto:opensim-dev-bounces at opensimulator.org] On Behalf Of Melanie
Sent: Sunday, November 08, 2015 02:35
To: opensim-dev at opensimulator.org
Subject: Re: [Opensim-dev] Still on Sim and Phys Frames per Second (FPS)

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
_______________________________________________
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