Re: Still on Sim and Phys Frames per Second (FPS)

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Still on Sim and Phys Frames per Second (FPS)

Seth Nygard
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
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Still on Sim and Phys Frames per Second (FPS)

AJLDuarte
Users and scripts perception of regions health based on "facial values" of
some of those stats was made before OpenSim.
Values were not scaled because it was funny. Its was needed, possible
because viewers then needed it, ported content need it, and Users minds
needed it.
And this was maintained for all this years. Forcing the change of contents
and user minds changing pure scale factor now serves no valid purpose.

Also those metrics displayed on viewers aren't truly "true" outside the
system where they designed to profile.

Even with our best efforts to make them give some valid qualitative
information.
Other statistics were added to better profile OpenSim performance.

Regards,
Ubit

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Seth Nygard
Sent: Saturday, November 07, 2015 15:38
To: [hidden email]
Subject: Re: [Opensim-dev] Still on Sim and Phys Frames per Second (FPS)

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
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Still on Sim and Phys Frames per Second (FPS)

Melanie-2
In reply to this post by Seth Nygard
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
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Still on Sim and Phys Frames per Second (FPS)

DZ-2
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 <[hidden email]> 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
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev


_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Still on Sim and Phys Frames per Second (FPS)

Melanie-2
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 <[hidden email]> 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
>> > [hidden email]
>> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> [hidden email]
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Still on Sim and Phys Frames per Second (FPS)

AJLDuarte
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: [hidden email]
[mailto:[hidden email]] On Behalf Of Melanie
Sent: Sunday, November 08, 2015 02:35
To: [hidden email]
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 <[hidden email]> 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
>> > [hidden email]
>> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> [hidden email]
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Still on Sim and Phys Frames per Second (FPS)

DZ-2
Call me  confused......  But  don't  tell me  I can't read  history!

This discussion is about a patch that was submitted in March  and  that patch was based on  questions that were raised in February.
According to my reading of the  discussions that Google has so kindly archived in my Opensim-dev folder the ONLY technical objection to the proposed patch dealt with an issue on the accuracy of time dilation factors.  

There were  numerous calls  for  people  who might be affected to speak up...   There were repeated calls  for  opinions  and  I see  +1's  from  Diva, BlueWall, Nebadon, and others  who saw fit to participate and  voice opinions.   The  ONLY objection raised to changing  to an accurate  reporting  was the assertion that "significant numbers of monitoring tools and  bots"  might need to be  reworked.   Divas call  for additional discussion delayed the implementation of the patch for  over  2 months   and  NO ONE objected to  modifying their  "numerous monitoring  scripts"  or  even commented on a potential negative impact.  

Its  been  months since the patch was applied  and the world hasn't stopped  turning.   Until just a few days  ago   there was  nary a PEEP  about  any adverse impact on the mailing lists...  WHERE is this  horde of angry users???   They  don't seem  to be  participating  in any of the OpenSim communities  I track...    then  after  almost a WHOLE DAY  a patch is  introduced  into the next  GIANT ( read  Impossible  to  parse through)  Update to reverse the  agreement that was  achieved.    Pardon me  if I  wonder   WTF ????  This sure makes me  confident!

Of  course there are always  delicious tidbits  of   perspective  that a look in the history books provides....    these  2   both made me  laugh....

Melanie <[hidden email]>
Apr 25

to opensim-dev 
I had been under the impression that the "fudge factor" on these stats was common knowledge.
Good arguments have been brought for changing them to provide accurate metrics and I find I can't sustain an objection to progress, especially since SL appears to have a limited shelf life these days.
Announcing this well enough should be sufficient, because I somehow can't see how anyone using advanced monitoring tools could not be subscribed to one of the mailing lists.

Whats  changed ???   
When  did the  consensus  achieved in the discussion group  become  so unimportant?

Now  we hear that "new  reporting  statistics"  will be implemented  to provide  "Accurate reporting" ...
....and  that  brings me  to the  last bit of  history  that sums  this whole thing up nicely....   a letter to the core devs  from teravus  dated  from  11/27 2009  

( if you don't feel like  tearing through the whole thing...  It is a call to start designing  accurate performance  measurement  metrics into the fabric of OpenSim  rather than  relying on fudged stats that might make  users "feel good " about  what is reported by the viewer.  It also discusses  the  absolute  NEED for accuracy so  performance progress  can be measured, and closes  with the fact  that the load tests  were  ultimately  FUTILE  without efforts  to move  forward and  CORRECT the  made up numbers)

Teravus Ovares <[hidden email]>
11/27/09

to opensim-dev 
Hey there,

A while back, we had somewhat reasonable statistics being generated and presented to the client.    They were not always accurate, but based on what I saw, I could, pretty much pin certain parts of the simulator as the limiting  factor during load tests.  

I'd say, the number 1 reason that they were semi-accurate and not accurate..  in the past..   is because nobody ever thought about instrumentation during the functionality design.     It was always 'tacked on later'.   One example of this..    is the current AssetCache implementation.   There's no way, currently, to know, at a glance..   how many external requests it has open.   Additionally, it will be extremely difficult to put one in because of the way the objects are designed and accessed.  To put one in, an event needs to be added to the IAssetService interface and each AssetCache implementation will need an interlocked int to count how many gets and puts it currently has open to the external data source as well as it's own event calling schedule.   Then, the IAssetService property in Scene, (AssetService) will need an event handler..   which updates the values in SimStatsReporter in Scene (StatsReporter).   This idea of external access resource instrumentation should really have been built in to the design of the AssetService. 

This last recent load test, there were no real statistics that I could use to determine what the limiting factor was. Time Dilation was pegged at 1.0..    even when the simulator was obviously struggling.    Total Frame time (MS) was -50ms even when the simulation MS was 850ms and the Physics ms was 250ms, so the inconsistencies made it impossible to know what part of the simulator was struggling.  Agent Updates were erratic..   sometimes high..
sometimes low when the simulator was fine and when it was struggling. Pending Uploads and Downloads were always 0, so there was no way to know how well the simulator was downloading and uploading assets to and from the grid.   Packet stats were non-existant, so there was no way to know how well the UDP handlers were faring under the load. When it crashed, it crashed with a mono based stack trace which pointed to out of memory errors, so the only way that you could, scientifically, find out what the issue is..   is to run a load test under a memory profiler.     We know, that running a public load test under a memory profiler is quite impractical. 

To make something better, I need to know two things, where it is, and where I want it to be.    How can we make OpenSimulator better if we don't have statistics that point to where we are currently?

On that note, I propose that, when designing objects for functionality in OpenSimulator, that we also consider if the objects should be instrumented and, what would be the best way to go about instrumenting the objects.  We should incorporate instrumentation into the design of the objects.   Some of that instrumentation is appropriate for a client to see, some of it might not be.   Consider that, many of them should be client facing and be included in the SimStats that get sent to the client..    so that we can have a reasonable idea of what's going on with a simulator at a glance.   Also, in the design of the instrumentation, we make sure that the instrumentation is accurate and
lightweight. 

The load test went reasonably...      but, we didn't get half of the information on the simulator that we needed to be able to improve it.


Please comment :)     I look forward to hearing your responses.

Regards

Teravus


I guess  it  should be  no surprise  that the  current call to improve and  provide  ACCURATE  performance statistics reporting  should be derided and dismissed.  ( apologies  to those members of  core   who  voted  +1 ad helped us  push this forward)  Not only are  members of the  communities calls ( AND contributions)  to improve this area of OpenSim ignored,   so are the  calls  from fellow  core devs about  what is needed  and  how it should be implemented...  Forgive me  if  I seem  JUST A BIT CYNICAL  that these  corrected stats  are forthcoming...

If you are going to accede to user demands,  maybe  you should  consider the effort  some of us users put into to getting this patch approved in the first place....  As  far as I can tell   we are the ones  contributing to the project by participating in this forum...   Please  feel free  to forward me  some names  and  email addresses  of these clamoring hordes  of unhappy  users   so I can search for their  outrage in my other  OpenSim related  groups and invite them to participate in  future  discussions  here...




On Sat, Nov 7, 2015 at 8:55 PM, AJLDuarte <[hidden email]> wrote:
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: [hidden email]
[mailto:[hidden email]] On Behalf Of Melanie
Sent: Sunday, November 08, 2015 02:35
To: [hidden email]
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 <[hidden email]> 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
>> > [hidden email]
>> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> [hidden email]
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev


_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Still on Sim and Phys Frames per Second (FPS)

Melanie-2
Hi,

what has changed is that I had never used the "Lag meter", because such a simplistic tool with "idiot lights" can't be accurate.
Therefore I didn't know it based it's findings on this stat.

It takes a while for information to filter back from users to grid operators, so I didn't haer about the problems in userland until a month or so ago.

Fact is that, previously unknown to me, the viewer uses this stat in an arithmetic fashion as opposed to just displaying it.

While the past has shown that script and module writers are happy to adapt to such changes, we know thet viewers are much slower to update. Also, some widely used viewers are no longer maintained at all.

Because if this, the _option_ of restoring the "fudge factor" was brought back. The default, which will be discussed further, is 1.0, which means accurate stats remain n effect, but grids with angry users will be able to restore fudged values to keep peace in their communities.

I still believe the accurate measurements should be reported, but we needs must bow to realities like the Lag Meter.

I have suggested to extend the reported data by a new field that represents accurate values so viewers can choose to diplay the accurate value and still have the normalized value available to drive the lag meter.

- Melanie

On 9 Nov 2015, at 04:04, dz <[hidden email]> wrote:

Call me  confused......  But  don't  tell me  I can't read  history!

This discussion is about a patch that was submitted in March  and  that patch was based on  questions that were raised in February.
According to my reading of the  discussions that Google has so kindly archived in my Opensim-dev folder the ONLY technical objection to the proposed patch dealt with an issue on the accuracy of time dilation factors.  

There were  numerous calls  for  people  who might be affected to speak up...   There were repeated calls  for  opinions  and  I see  +1's  from  Diva, BlueWall, Nebadon, and others  who saw fit to participate and  voice opinions.   The  ONLY objection raised to changing  to an accurate  reporting  was the assertion that "significant numbers of monitoring tools and  bots"  might need to be  reworked.   Divas call  for additional discussion delayed the implementation of the patch for  over  2 months   and  NO ONE objected to  modifying their  "numerous monitoring  scripts"  or  even commented on a potential negative impact.  

Its  been  months since the patch was applied  and the world hasn't stopped  turning.   Until just a few days  ago   there was  nary a PEEP  about  any adverse impact on the mailing lists...  WHERE is this  horde of angry users???   They  don't seem  to be  participating  in any of the OpenSim communities  I track...    then  after  almost a WHOLE DAY  a patch is  introduced  into the next  GIANT ( read  Impossible  to  parse through)  Update to reverse the  agreement that was  achieved.    Pardon me  if I  wonder   WTF ????  This sure makes me  confident!

Of  course there are always  delicious tidbits  of   perspective  that a look in the history books provides....    these  2   both made me  laugh....

Melanie <[hidden email]>
Apr 25

to opensim-dev 
I had been under the impression that the "fudge factor" on these stats was common knowledge.
Good arguments have been brought for changing them to provide accurate metrics and I find I can't sustain an objection to progress, especially since SL appears to have a limited shelf life these days.
Announcing this well enough should be sufficient, because I somehow can't see how anyone using advanced monitoring tools could not be subscribed to one of the mailing lists.

Whats  changed ???   
When  did the  consensus  achieved in the discussion group  become  so unimportant?

Now  we hear that "new  reporting  statistics"  will be implemented  to provide  "Accurate reporting" ...
....and  that  brings me  to the  last bit of  history  that sums  this whole thing up nicely....   a letter to the core devs  from teravus  dated  from  11/27 2009  

( if you don't feel like  tearing through the whole thing...  It is a call to start designing  accurate performance  measurement  metrics into the fabric of OpenSim  rather than  relying on fudged stats that might make  users "feel good " about  what is reported by the viewer.  It also discusses  the  absolute  NEED for accuracy so  performance progress  can be measured, and closes  with the fact  that the load tests  were  ultimately  FUTILE  without efforts  to move  forward and  CORRECT the  made up numbers)

Teravus Ovares <[hidden email]>
11/27/09

to opensim-dev 
Hey there,

A while back, we had somewhat reasonable statistics being generated and presented to the client.    They were not always accurate, but based on what I saw, I could, pretty much pin certain parts of the simulator as the limiting  factor during load tests.  

I'd say, the number 1 reason that they were semi-accurate and not accurate..  in the past..   is because nobody ever thought about instrumentation during the functionality design.     It was always 'tacked on later'.   One example of this..    is the current AssetCache implementation.   There's no way, currently, to know, at a glance..   how many external requests it has open.   Additionally, it will be extremely difficult to put one in because of the way the objects are designed and accessed.  To put one in, an event needs to be added to the IAssetService interface and each AssetCache implementation will need an interlocked int to count how many gets and puts it currently has open to the external data source as well as it's own event calling schedule.   Then, the IAssetService property in Scene, (AssetService) will need an event handler..   which updates the values in SimStatsReporter in Scene (StatsReporter).   This idea of external access resource instrumentation should really have been built in to the design of the AssetService. 

This last recent load test, there were no real statistics that I could use to determine what the limiting factor was. Time Dilation was pegged at 1.0..    even when the simulator was obviously struggling.    Total Frame time (MS) was -50ms even when the simulation MS was 850ms and the Physics ms was 250ms, so the inconsistencies made it impossible to know what part of the simulator was struggling.  Agent Updates were erratic..   sometimes high..
sometimes low when the simulator was fine and when it was struggling. Pending Uploads and Downloads were always 0, so there was no way to know how well the simulator was downloading and uploading assets to and from the grid.   Packet stats were non-existant, so there was no way to know how well the UDP handlers were faring under the load. When it crashed, it crashed with a mono based stack trace which pointed to out of memory errors, so the only way that you could, scientifically, find out what the issue is..   is to run a load test under a memory profiler.     We know, that running a public load test under a memory profiler is quite impractical. 

To make something better, I need to know two things, where it is, and where I want it to be.    How can we make OpenSimulator better if we don't have statistics that point to where we are currently?

On that note, I propose that, when designing objects for functionality in OpenSimulator, that we also consider if the objects should be instrumented and, what would be the best way to go about instrumenting the objects.  We should incorporate instrumentation into the design of the objects.   Some of that instrumentation is appropriate for a client to see, some of it might not be.   Consider that, many of them should be client facing and be included in the SimStats that get sent to the client..    so that we can have a reasonable idea of what's going on with a simulator at a glance.   Also, in the design of the instrumentation, we make sure that the instrumentation is accurate and
lightweight. 

The load test went reasonably...      but, we didn't get half of the information on the simulator that we needed to be able to improve it.


Please comment :)     I look forward to hearing your responses.

Regards

Teravus


I guess  it  should be  no surprise  that the  current call to improve and  provide  ACCURATE  performance statistics reporting  should be derided and dismissed.  ( apologies  to those members of  core   who  voted  +1 ad helped us  push this forward)  Not only are  members of the  communities calls ( AND contributions)  to improve this area of OpenSim ignored,   so are the  calls  from fellow  core devs about  what is needed  and  how it should be implemented...  Forgive me  if  I seem  JUST A BIT CYNICAL  that these  corrected stats  are forthcoming...

If you are going to accede to user demands,  maybe  you should  consider the effort  some of us users put into to getting this patch approved in the first place....  As  far as I can tell   we are the ones  contributing to the project by participating in this forum...   Please  feel free  to forward me  some names  and  email addresses  of these clamoring hordes  of unhappy  users   so I can search for their  outrage in my other  OpenSim related  groups and invite them to participate in  future  discussions  here...




On Sat, Nov 7, 2015 at 8:55 PM, AJLDuarte <[hidden email]> wrote:
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: [hidden email]
[mailto:[hidden email]] On Behalf Of Melanie
Sent: Sunday, November 08, 2015 02:35
To: [hidden email]
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 <[hidden email]> 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
>> > [hidden email]
>> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> [hidden email]
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Non-DoD Source] Re: Still on Sim and Phys Frames per Second (FPS) (UNCLASSIFIED)

Maxwell, Douglas CIV USARMY RDECOM ARL (US)
In reply to this post by DZ-2
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



-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of dz
Sent: Saturday, November 07, 2015 8:54 PM
To: [hidden email]
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 <[hidden email] <
Caution-mailto:[hidden email] > > 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
        > [hidden email] <
Caution-mailto:[hidden email] >
        > Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev <
Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >

        _______________________________________________
        Opensim-dev mailing list
        [hidden email] < Caution-mailto:[hidden email]
 >
        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
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Non-DoD Source] Re: Still on Sim and Phys Frames per Second (FPS) (UNCLASSIFIED)

Zadark Portal
+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)


On 9 November 2015 at 16:37, Maxwell, Douglas CIV USARMY RDECOM ARL (US) <[hidden email]> 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) <a href="tel:%28407%29%20242-0209" value="+14072420209">(407) 242-0209



-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of dz
Sent: Saturday, November 07, 2015 8:54 PM
To: [hidden email]
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 <[hidden email] <
Caution-mailto:[hidden email] > > 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
        > [hidden email] <
Caution-mailto:[hidden email] >
        > Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev <
Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >

        _______________________________________________
        Opensim-dev mailing list
        [hidden email] < Caution-mailto:[hidden email]
 >
        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
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev



_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Non-DoD Source] Re: Still on Sim and Phys Frames per Second (FPS) (UNCLASSIFIED)

Terry Ford-2
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)


On 9 November 2015 at 16:37, Maxwell, Douglas CIV USARMY RDECOM ARL (US) <[hidden email]> 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) <a moz-do-not-send="true" href="tel:%28407%29%20242-0209" value="+14072420209">(407) 242-0209



-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of dz
Sent: Saturday, November 07, 2015 8:54 PM
To: [hidden email]
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 <[hidden email] <
Caution-mailto:[hidden email] > > 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
        > [hidden email] <
Caution-mailto:[hidden email] >
        > Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev <
Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >

        _______________________________________________
        Opensim-dev mailing list
        [hidden email] < Caution-mailto:[hidden email]
 >
        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
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev




_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

--
---------------------
Terry Ford
DigiWorldz Grid
http://digiworldz.com

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Non-DoD Source] Re: Still on Sim and Phys Frames per Second (FPS) (UNCLASSIFIED)

Melanie-2
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) <[hidden email]
>> <mailto:[hidden email]>> 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: [hidden email]
>>     <mailto:[hidden email]>
>>     [mailto:[hidden email]
>>     <mailto:[hidden email]>] On Behalf Of dz
>>     Sent: Saturday, November 07, 2015 8:54 PM
>>     To: [hidden email]
>>     <mailto:[hidden email]>
>>     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 <[hidden email]
>>     <mailto:[hidden email]> <
>>     Caution-mailto:[hidden email] <mailto:[hidden email]> > >
>>     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
>>             > [hidden email]
>>     <mailto:[hidden email]> <
>>     Caution-mailto:[hidden email]
>>     <mailto:[hidden email]> >
>>             >
>>     Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>     <
>>     Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>     >
>>
>>             _______________________________________________
>>             Opensim-dev mailing list
>>     [hidden email]
>>     <mailto:[hidden email]> <
>>     Caution-mailto:[hidden email]
>>     <mailto:[hidden email]>
>>      >
>>            
>>     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
>>     [hidden email] <mailto:[hidden email]>
>>     http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
>>
>>
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> [hidden email]
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Non-DoD Source] Re: Still on Sim and Phys Frames per Second (FPS) (UNCLASSIFIED)

Michael Emory Cerquoni

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" <[hidden email]> 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) <[hidden email]
>> <mailto:[hidden email]>> 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: [hidden email]
>>     <mailto:[hidden email]>
>>     [mailto:[hidden email]
>>     <mailto:[hidden email]>] On Behalf Of dz
>>     Sent: Saturday, November 07, 2015 8:54 PM
>>     To: [hidden email]
>>     <mailto:[hidden email]>
>>     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 <[hidden email]
>>     <mailto:[hidden email]> <
>>     Caution-mailto:[hidden email] <mailto:[hidden email]> > >
>>     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
>>             > [hidden email]
>>     <mailto:[hidden email]> <
>>     Caution-mailto:[hidden email]
>>     <mailto:[hidden email]> >
>>             >
>>     Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>     <
>>     Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>     >
>>
>>             _______________________________________________
>>             Opensim-dev mailing list
>>     [hidden email]
>>     <mailto:[hidden email]> <
>>     Caution-mailto:[hidden email]
>>     <mailto:[hidden email]>
>>      >
>>
>>     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
>>     [hidden email] <mailto:[hidden email]>
>>     http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
>>
>>
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> [hidden email]
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Non-DoD Source] Re: Still on Sim and Phys Frames per Second (FPS) (UNCLASSIFIED)

Terry Ford-2
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" <[hidden email]> 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) <[hidden email]
>> <mailto:[hidden email]>> 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 <a class="moz-txt-link-rfc2396E" href="tel:%28407%29%20242-0209"><tel:%28407%29%20242-0209>
>>
>>
>>
>>     -----Original Message-----
>>     From: [hidden email]
>>     <mailto:[hidden email]>
>>     [mailto:[hidden email]
>>     <mailto:[hidden email]>] On Behalf Of dz
>>     Sent: Saturday, November 07, 2015 8:54 PM
>>     To: [hidden email]
>>     <mailto:[hidden email]>
>>     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 <[hidden email]
>>     <mailto:[hidden email]> <
>>     Caution-mailto:[hidden email] <mailto:[hidden email]> > >
>>     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
>>             > [hidden email]
>>     <mailto:[hidden email]> <
>>     Caution-mailto:[hidden email]
>>     <mailto:[hidden email]> >
>>             >
>>     Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>     <
>>     Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>     >
>>
>>             _______________________________________________
>>             Opensim-dev mailing list
>>     [hidden email]
>>     <mailto:[hidden email]> <
>>     Caution-mailto:[hidden email]
>>     <mailto:[hidden email]>
>>      >
>>
>>     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
>>     [hidden email] <mailto:[hidden email]>
>>     http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
>>
>>
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> [hidden email]
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev


_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

--
---------------------
Terry Ford
DigiWorldz Grid
http://digiworldz.com

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Non-DoD Source] Re: Still on Sim and Phys Frames per Second (FPS) (UNCLASSIFIED)

Melanie-2
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" <[hidden email]
>> <mailto:[hidden email]>> 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) <[hidden email]
>>     <mailto:[hidden email]>
>>     >> <mailto:[hidden email]
>>     <mailto:[hidden email]>>> 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: [hidden email]
>>     <mailto:[hidden email]>
>>     >>     <mailto:[hidden email]
>>     <mailto:[hidden email]>>
>>     >>     [mailto:[hidden email]
>>     <mailto:[hidden email]>
>>     >>     <mailto:[hidden email]
>>     <mailto:[hidden email]>>] On Behalf Of dz
>>     >>     Sent: Saturday, November 07, 2015 8:54 PM
>>     >>     To: [hidden email]
>>     <mailto:[hidden email]>
>>     >>     <mailto:[hidden email]
>>     <mailto:[hidden email]>>
>>     >>     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 <[hidden email]
>>     <mailto:[hidden email]>
>>     >>     <mailto:[hidden email] <mailto:[hidden email]>> <
>>     >>     Caution-mailto:[hidden email]
>>     <mailto:[hidden email]> <mailto:[hidden email]
>>     <mailto:[hidden email]>> > >
>>     >>     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
>>     >>             > [hidden email]
>>     <mailto:[hidden email]>
>>     >>     <mailto:[hidden email]
>>     <mailto:[hidden email]>> <
>>     >>     Caution-mailto:[hidden email]
>>     <mailto:[hidden email]>
>>     >>     <mailto:[hidden email]
>>     <mailto:[hidden email]>> >
>>     >>             >
>>     >>  
>>      Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>     >>     <
>>     >>  
>>      Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>     >>     >
>>     >>
>>     >>  _______________________________________________
>>     >>             Opensim-dev mailing list
>>     >> [hidden email]
>>     <mailto:[hidden email]>
>>     >>     <mailto:[hidden email]
>>     <mailto:[hidden email]>> <
>>     >>     Caution-mailto:[hidden email]
>>     <mailto:[hidden email]>
>>     >>     <mailto:[hidden email]
>>     <mailto:[hidden email]>>
>>     >>      >
>>     >>
>>     >>  
>>      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
>>     >> [hidden email]
>>     <mailto:[hidden email]>
>>     <mailto:[hidden email]
>>     <mailto:[hidden email]>>
>>     >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>     >>
>>     >>
>>     >>
>>     >>
>>     >> _______________________________________________
>>     >> Opensim-dev mailing list
>>     >> [hidden email]
>>     <mailto:[hidden email]>
>>     >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>     >
>>     >
>>     >
>>     >
>>     > _______________________________________________
>>     > Opensim-dev mailing list
>>     > [hidden email] <mailto:[hidden email]>
>>     > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>     _______________________________________________
>>     Opensim-dev mailing list
>>     [hidden email] <mailto:[hidden email]>
>>     http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
>>
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> [hidden email]
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Non-DoD Source] Re: Still on Sim and Phys Frames per Second (FPS) (UNCLASSIFIED)

Glenn Martin
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 <[hidden email]> 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" <[hidden email]
>>> <mailto:[hidden email]>> 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) <[hidden email]
>>>    <mailto:[hidden email]>
>>>>> <mailto:[hidden email]
>>>    <mailto:[hidden email]>>> 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: [hidden email]
>>>    <mailto:[hidden email]>
>>>>>    <mailto:[hidden email]
>>>    <mailto:[hidden email]>>
>>>>>    [mailto:[hidden email]
>>>    <mailto:[hidden email]>
>>>>>    <mailto:[hidden email]
>>>    <mailto:[hidden email]>>] On Behalf Of dz
>>>>>    Sent: Saturday, November 07, 2015 8:54 PM
>>>>>    To: [hidden email]
>>>    <mailto:[hidden email]>
>>>>>    <mailto:[hidden email]
>>>    <mailto:[hidden email]>>
>>>>>    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 <[hidden email]
>>>    <mailto:[hidden email]>
>>>>>    <mailto:[hidden email] <mailto:[hidden email]>> <
>>>>>    Caution-mailto:[hidden email]
>>>    <mailto:[hidden email]> <mailto:[hidden email]
>>>    <mailto:[hidden email]>> > >
>>>>>    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
>>>>>> [hidden email]
>>>    <mailto:[hidden email]>
>>>>>    <mailto:[hidden email]
>>>    <mailto:[hidden email]>> <
>>>>>    Caution-mailto:[hidden email]
>>>    <mailto:[hidden email]>
>>>>>    <mailto:[hidden email]
>>>    <mailto:[hidden email]>> >
>>>     Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>>>    <
>>>     Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>>>
>>>>> _______________________________________________
>>>>>            Opensim-dev mailing list
>>>>> [hidden email]
>>>    <mailto:[hidden email]>
>>>>>    <mailto:[hidden email]
>>>    <mailto:[hidden email]>> <
>>>>>    Caution-mailto:[hidden email]
>>>    <mailto:[hidden email]>
>>>>>    <mailto:[hidden email]
>>>    <mailto:[hidden email]>>
>>>     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
>>>>> [hidden email]
>>>    <mailto:[hidden email]>
>>>    <mailto:[hidden email]
>>>    <mailto:[hidden email]>>
>>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Opensim-dev mailing list
>>>>> [hidden email]
>>>    <mailto:[hidden email]>
>>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Opensim-dev mailing list
>>>> [hidden email] <mailto:[hidden email]>
>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>    _______________________________________________
>>>    Opensim-dev mailing list
>>>    [hidden email] <mailto:[hidden email]>
>>>    http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> [hidden email]
>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
>>
>>
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> [hidden email]
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Non-DoD Source] Re: Still on Sim and Phys Frames per Second (FPS) (UNCLASSIFIED)

Melanie-2
If it were just a displayed value, i'd concur. However, not
normalizing the value causes an actual malfunction and the viewer
developers have no way to fix it because we don't provide the data
that is needed to do so.

- Melanie

On 09/11/2015 19:11, Glenn Martin wrote:

> 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 <[hidden email]> 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" <[hidden email]
>>>> <mailto:[hidden email]>> 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) <[hidden email]
>>>>    <mailto:[hidden email]>
>>>>>> <mailto:[hidden email]
>>>>    <mailto:[hidden email]>>> 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: [hidden email]
>>>>    <mailto:[hidden email]>
>>>>>>    <mailto:[hidden email]
>>>>    <mailto:[hidden email]>>
>>>>>>    [mailto:[hidden email]
>>>>    <mailto:[hidden email]>
>>>>>>    <mailto:[hidden email]
>>>>    <mailto:[hidden email]>>] On Behalf Of dz
>>>>>>    Sent: Saturday, November 07, 2015 8:54 PM
>>>>>>    To: [hidden email]
>>>>    <mailto:[hidden email]>
>>>>>>    <mailto:[hidden email]
>>>>    <mailto:[hidden email]>>
>>>>>>    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 <[hidden email]
>>>>    <mailto:[hidden email]>
>>>>>>    <mailto:[hidden email] <mailto:[hidden email]>> <
>>>>>>    Caution-mailto:[hidden email]
>>>>    <mailto:[hidden email]> <mailto:[hidden email]
>>>>    <mailto:[hidden email]>> > >
>>>>>>    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
>>>>>>> [hidden email]
>>>>    <mailto:[hidden email]>
>>>>>>    <mailto:[hidden email]
>>>>    <mailto:[hidden email]>> <
>>>>>>    Caution-mailto:[hidden email]
>>>>    <mailto:[hidden email]>
>>>>>>    <mailto:[hidden email]
>>>>    <mailto:[hidden email]>> >
>>>>     Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>>>>    <
>>>>     Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>>>>
>>>>>> _______________________________________________
>>>>>>            Opensim-dev mailing list
>>>>>> [hidden email]
>>>>    <mailto:[hidden email]>
>>>>>>    <mailto:[hidden email]
>>>>    <mailto:[hidden email]>> <
>>>>>>    Caution-mailto:[hidden email]
>>>>    <mailto:[hidden email]>
>>>>>>    <mailto:[hidden email]
>>>>    <mailto:[hidden email]>>
>>>>     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
>>>>>> [hidden email]
>>>>    <mailto:[hidden email]>
>>>>    <mailto:[hidden email]
>>>>    <mailto:[hidden email]>>
>>>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Opensim-dev mailing list
>>>>>> [hidden email]
>>>>    <mailto:[hidden email]>
>>>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Opensim-dev mailing list
>>>>> [hidden email] <mailto:[hidden email]>
>>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>>    _______________________________________________
>>>>    Opensim-dev mailing list
>>>>    [hidden email] <mailto:[hidden email]>
>>>>    http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Opensim-dev mailing list
>>>> [hidden email]
>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> [hidden email]
>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>> _______________________________________________
>> Opensim-dev mailing list
>> [hidden email]
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Non-DoD Source] Re: Still on Sim and Phys Frames per Second (FPS) (UNCLASSIFIED)

AJLDuarte
In reply to this post by Maxwell, Douglas CIV USARMY RDECOM ARL (US)
Hi doug,
        No flames assumed.
        I tried to explain within my limited English skills, my understanding of the nature of the issue on OpenSim. Melanie and others expressed it better possible.
        About the use of the statistics sent to viewers as profiling tools. Guess it is not necessary to mention that we do know about the scaling factor and have a idea of reliability of some parameters and even know the ones still totally broken.
        For more complete profile the short answer is: we don’t use them.
       
        Our current code already contributions that did result from detailed profiling with goals similar to yours. As example amongst others, I can remember the work done by Intel teams. The article starting at
https://software.intel.com/en-us/articles/opensimulator-virtual-world-server-case-study-part-1
By Robert Adams, (that you already know as a member of our team) is just a small expression what they did.

This just to mention one organization with well defined work methodologies like yours.

Meanwhile we will try to fake very accurately.

Regards,
Leal Duarte(Ubit Umarov)
       

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Maxwell, Douglas CIV USARMY RDECOM ARL (US)
Sent: Monday, November 09, 2015 16:37
To: [hidden email]
Subject: Re: [Opensim-dev] [Non-DoD Source] Re: Still on Sim and Phys Frames per Second (FPS) (UNCLASSIFIED)

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



-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of dz
Sent: Saturday, November 07, 2015 8:54 PM
To: [hidden email]
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 <[hidden email] < Caution-mailto:[hidden email] > > 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
        > [hidden email] <
Caution-mailto:[hidden email] >
        > Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev <
Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >

        _______________________________________________
        Opensim-dev mailing list
        [hidden email] < Caution-mailto:[hidden email]
 >
        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
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Loading...