Still on Sim and Phys Frames per Second (FPS)

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

Still on Sim and Phys Frames per Second (FPS)

Seth Nygard
Let the FPS wars begin so there can be confusion everywhere...
Now those that want to can set a ridiculous fudge factor and show
11000000FPS - WOW, look, waaaaaaay faster than "that other grid"!

I firmly disagree in adding anything that allows artificially inflated
metrics for any value.  At this stage the configurable fudge factor is
an even worse "fix" IMHO.

The correct fix is really to communicate the correct value(s) and put
pressure on the viewer developers to fix their lag calculation(s).  
People can be expected to update their viewer(s) which is not an
unrealistic expectation.  People running old and/or unsupported viewers
already have a plethora of issues they need to be aware of and things
that don't work right, so why is the lag indicator any different?

If we must have this user configurable then, instead of a fudge factor
value it should be a simple boolean setting such as;
ShowArtificiallyInflatedAndIncorrectFPS = false;
ShowArtificiallyInflatedAndIncorrectFPS = true;

On my grid I have made it a point to inform everyone that the calculated
lag indicator is broken and the 11FPS is in the correct and normal
value.  I also point out that what used to be shown was in fact a
falsified and artificially inflated value to make things look like "that
other grid".  Most people simple say "Oh yeah, I never paid attention to
that anyhow.  It doesn't work right any of the time anyhow".  Many then
say they looked at the wiki but couldn't find any information on what to
expect.

If whenever people ask for documentation the standard reply from the dev
community is "read the code" then why is it so hard to ask for, and
expect the viewers to be fixed and updated?

-Seth

On 09/11/2015 8:56 AM, [hidden email] wrote:

> Send Opensim-dev mailing list submissions to
> [hidden email]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> or, via email, send a message with subject or body 'help' to
> [hidden email]
>
> You can reach the person managing the list at
> [hidden email]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Opensim-dev digest..."
>
>
> Today's Topics:
>
>     1. Re: Still on Sim and Phys Frames per Second (FPS) (Melanie IMAP)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 9 Nov 2015 14:56:22 +0100
> From: Melanie IMAP <[hidden email]>
> To: "[hidden email]" <[hidden email]>
> Subject: Re: [Opensim-dev] Still on Sim and Phys Frames per Second
> (FPS)
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset="us-ascii"
>
> 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
 re

>   ally 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20151109/594b6922/attachment.html>
>
> ------------------------------
>
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
>
> End of Opensim-dev Digest, Vol 20, Issue 17
> *******************************************


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

Kevin Cozens
On 15-11-09 10:05 AM, Seth Nygard wrote:
> Let the FPS wars begin so there can be confusion everywhere...
> Now those that want to can set a ridiculous fudge factor and show
> 11000000FPS - WOW, look, waaaaaaay faster than "that other grid"!
[snip]
> If we must have this user configurable then, instead of a fudge factor value
> it should be a simple boolean setting such as;
> ShowArtificiallyInflatedAndIncorrectFPS = false;
> ShowArtificiallyInflatedAndIncorrectFPS = true;

I'm with Seth on the idea of having a boolean setting. Either show the
incorrect and inflated stats or show the real stats. Allowing the fudge
factor to be easily changed by operators via a setting in the ini seems like
a really bad idea.

--
Cheers!

Kevin.

http://www.ve3syb.ca/           |"Nerds make the shiny things that distract
Owner of Elecraft K2 #2172      | the mouth-breathers, and that's why we're
                                 | powerful!"
#include <disclaimer/favourite> |             --Chris Hardwick
_______________________________________________
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
In reply to this post by Seth Nygard
Hi,
        I Agree with Dan, Seth and others.
        StatisticsFPSfactor  was a increase in configuration complexity.
        Its now replaced by Normalized55FPS than can be set true or false.
        If true a full normalization to nominal 55FPS is done.
        If false the scaling part of the normalization is not done, (i.e.
reported values are normalized to nominal 1/FrameTime rate).
        With current code the scale factor is 55 * FrameTime (5 with
defaults).

        Normalized55FPS now ON by default.

        (This changes are still only available on avinationmerge branch)

Regards.



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

Terry Ford-2
In reply to this post by Seth Nygard
+1 On seth's idea..
I too would prefer to see only allow the option of either correct or false values.

~Terry

On 11/9/2015 10:05 AM, Seth Nygard wrote:
Let the FPS wars begin so there can be confusion everywhere...
Now those that want to can set a ridiculous fudge factor and show 11000000FPS - WOW, look, waaaaaaay faster than "that other grid"!

I firmly disagree in adding anything that allows artificially inflated metrics for any value.  At this stage the configurable fudge factor is an even worse "fix" IMHO.

The correct fix is really to communicate the correct value(s) and put pressure on the viewer developers to fix their lag calculation(s).  People can be expected to update their viewer(s) which is not an unrealistic expectation.  People running old and/or unsupported viewers already have a plethora of issues they need to be aware of and things that don't work right, so why is the lag indicator any different?

If we must have this user configurable then, instead of a fudge factor value it should be a simple boolean setting such as;
ShowArtificiallyInflatedAndIncorrectFPS = false;
ShowArtificiallyInflatedAndIncorrectFPS = true;

On my grid I have made it a point to inform everyone that the calculated lag indicator is broken and the 11FPS is in the correct and normal value.  I also point out that what used to be shown was in fact a falsified and artificially inflated value to make things look like "that other grid".  Most people simple say "Oh yeah, I never paid attention to that anyhow.  It doesn't work right any of the time anyhow".  Many then say they looked at the wiki but couldn't find any information on what to expect.

If whenever people ask for documentation the standard reply from the dev community is "read the code" then why is it so hard to ask for, and expect the viewers to be fixed and updated?

-Seth

On 09/11/2015 8:56 AM, [hidden email] wrote:
Send Opensim-dev mailing list submissions to
    [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
    http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
or, via email, send a message with subject or body 'help' to
    [hidden email]

You can reach the person managing the list at
    [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Opensim-dev digest..."


Today's Topics:

    1. Re: Still on Sim and Phys Frames per Second (FPS) (Melanie IMAP)


----------------------------------------------------------------------

Message: 1
Date: Mon, 9 Nov 2015 14:56:22 +0100
From: Melanie IMAP [hidden email]
To: [hidden email] [hidden email]
Subject: Re: [Opensim-dev] Still on Sim and Phys Frames per Second
    (FPS)
Message-ID: [hidden email]
Content-Type: text/plain; charset="us-ascii"

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
re
  ally 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]
[[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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20151109/594b6922/attachment.html>

------------------------------

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


End of Opensim-dev Digest, Vol 20, Issue 17
*******************************************


_______________________________________________
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: Still on Sim and Phys Frames per Second (FPS)

Jak Daniels
+1 also.

Jak

On 09/11/2015 16:22, Terry Ford wrote:
+1 On seth's idea..
I too would prefer to see only allow the option of either correct or false values.

~Terry

On 11/9/2015 10:05 AM, Seth Nygard wrote:
Let the FPS wars begin so there can be confusion everywhere...
Now those that want to can set a ridiculous fudge factor and show 11000000FPS - WOW, look, waaaaaaay faster than "that other grid"!

I firmly disagree in adding anything that allows artificially inflated metrics for any value.  At this stage the configurable fudge factor is an even worse "fix" IMHO.

The correct fix is really to communicate the correct value(s) and put pressure on the viewer developers to fix their lag calculation(s).  People can be expected to update their viewer(s) which is not an unrealistic expectation.  People running old and/or unsupported viewers already have a plethora of issues they need to be aware of and things that don't work right, so why is the lag indicator any different?

If we must have this user configurable then, instead of a fudge factor value it should be a simple boolean setting such as;
ShowArtificiallyInflatedAndIncorrectFPS = false;
ShowArtificiallyInflatedAndIncorrectFPS = true;

On my grid I have made it a point to inform everyone that the calculated lag indicator is broken and the 11FPS is in the correct and normal value.  I also point out that what used to be shown was in fact a falsified and artificially inflated value to make things look like "that other grid".  Most people simple say "Oh yeah, I never paid attention to that anyhow.  It doesn't work right any of the time anyhow".  Many then say they looked at the wiki but couldn't find any information on what to expect.

If whenever people ask for documentation the standard reply from the dev community is "read the code" then why is it so hard to ask for, and expect the viewers to be fixed and updated?

-Seth

On 09/11/2015 8:56 AM, [hidden email] wrote:
Send Opensim-dev mailing list submissions to
    [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
    http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
or, via email, send a message with subject or body 'help' to
    [hidden email]

You can reach the person managing the list at
    [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Opensim-dev digest..."


Today's Topics:

    1. Re: Still on Sim and Phys Frames per Second (FPS) (Melanie IMAP)


----------------------------------------------------------------------

Message: 1
Date: Mon, 9 Nov 2015 14:56:22 +0100
From: Melanie IMAP [hidden email]
To: [hidden email] [hidden email]
Subject: Re: [Opensim-dev] Still on Sim and Phys Frames per Second
    (FPS)
Message-ID: [hidden email]
Content-Type: text/plain; charset="us-ascii"

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
re
  ally 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]
[[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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20151109/594b6922/attachment.html>

------------------------------

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


End of Opensim-dev Digest, Vol 20, Issue 17
*******************************************


_______________________________________________
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


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

Shy Robbiani
+1 too. I totally agree with anything said by Seth.

On Mon, Nov 9, 2015 at 5:26 PM, Jak Daniels <[hidden email]> wrote:
+1 also.

Jak


On 09/11/2015 16:22, Terry Ford wrote:
+1 On seth's idea..
I too would prefer to see only allow the option of either correct or false values.

~Terry

On 11/9/2015 10:05 AM, Seth Nygard wrote:
Let the FPS wars begin so there can be confusion everywhere...
Now those that want to can set a ridiculous fudge factor and show 11000000FPS - WOW, look, waaaaaaay faster than "that other grid"!

I firmly disagree in adding anything that allows artificially inflated metrics for any value.  At this stage the configurable fudge factor is an even worse "fix" IMHO.

The correct fix is really to communicate the correct value(s) and put pressure on the viewer developers to fix their lag calculation(s).  People can be expected to update their viewer(s) which is not an unrealistic expectation.  People running old and/or unsupported viewers already have a plethora of issues they need to be aware of and things that don't work right, so why is the lag indicator any different?

If we must have this user configurable then, instead of a fudge factor value it should be a simple boolean setting such as;
ShowArtificiallyInflatedAndIncorrectFPS = false;
ShowArtificiallyInflatedAndIncorrectFPS = true;

On my grid I have made it a point to inform everyone that the calculated lag indicator is broken and the 11FPS is in the correct and normal value.  I also point out that what used to be shown was in fact a falsified and artificially inflated value to make things look like "that other grid".  Most people simple say "Oh yeah, I never paid attention to that anyhow.  It doesn't work right any of the time anyhow".  Many then say they looked at the wiki but couldn't find any information on what to expect.

If whenever people ask for documentation the standard reply from the dev community is "read the code" then why is it so hard to ask for, and expect the viewers to be fixed and updated?

-Seth

On 09/11/2015 8:56 AM, [hidden email] wrote:
Send Opensim-dev mailing list submissions to
    [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
    http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
or, via email, send a message with subject or body 'help' to
    [hidden email]

You can reach the person managing the list at
    [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Opensim-dev digest..."


Today's Topics:

    1. Re: Still on Sim and Phys Frames per Second (FPS) (Melanie IMAP)


----------------------------------------------------------------------

Message: 1
Date: Mon, 9 Nov 2015 14:56:22 +0100
From: Melanie IMAP [hidden email]
To: [hidden email] [hidden email]
Subject: Re: [Opensim-dev] Still on Sim and Phys Frames per Second
    (FPS)
Message-ID: [hidden email]
Content-Type: text/plain; charset="us-ascii"

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
re
  ally 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]
[[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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20151109/594b6922/attachment.html>

------------------------------

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


End of Opensim-dev Digest, Vol 20, Issue 17
*******************************************


_______________________________________________
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


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

Ai Austin-2
In reply to this post by Seth Nygard
Ai Austin write:
>We ought to try to work with viewer developers to ensure their
>OpenSim variant or code adjustments can properly can do things with
>accurate stats. Melanie has made some suggestions of having
>capabilities or parameters that can be communicated to viewers for
>reporting the expected frame rates. Do we need to call it a "fudge
>factor" - or just an anticipated rate for "average"?  Communicating
>grid and sim properties to the viewer is becoming more common for a
>range of things that are not in SL.

Shy Robbiani wrote:
>If we must have this user configurable then, instead of a fudge
>factor value it should be a simple boolean setting such as;
>ShowArtificiallyInflatedAndIncorrectFPS = false;
>ShowArtificiallyInflatedAndIncorrectFPS = true;
>
>On my grid I have made it a point to inform everyone that the
>calculated lag indicator is broken and the 11FPS is in the correct
>and normal value.


I was getting at something like this in my contribution to the
discussion... but not perpetuating, as viewers develop, the wrong lag
computation in the case of OpenSim... i.e. preferring something like...

NormalFPS=10.666667

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

Garmin Kawaguichi
In reply to this post by Seth Nygard
I quite agree with what Seth wrote.

GCI


Le 09/11/2015 16:05, Seth Nygard a écrit :
Let the FPS wars begin so there can be confusion everywhere...
Now those that want to can set a ridiculous fudge factor and show 11000000FPS - WOW, look, waaaaaaay faster than "that other grid"!

I firmly disagree in adding anything that allows artificially inflated metrics for any value.  At this stage the configurable fudge factor is an even worse "fix" IMHO.

The correct fix is really to communicate the correct value(s) and put pressure on the viewer developers to fix their lag calculation(s).  People can be expected to update their viewer(s) which is not an unrealistic expectation.  People running old and/or unsupported viewers already have a plethora of issues they need to be aware of and things that don't work right, so why is the lag indicator any different?

If we must have this user configurable then, instead of a fudge factor value it should be a simple boolean setting such as;
ShowArtificiallyInflatedAndIncorrectFPS = false;
ShowArtificiallyInflatedAndIncorrectFPS = true;

On my grid I have made it a point to inform everyone that the calculated lag indicator is broken and the 11FPS is in the correct and normal value.  I also point out that what used to be shown was in fact a falsified and artificially inflated value to make things look like "that other grid".  Most people simple say "Oh yeah, I never paid attention to that anyhow.  It doesn't work right any of the time anyhow".  Many then say they looked at the wiki but couldn't find any information on what to expect.

If whenever people ask for documentation the standard reply from the dev community is "read the code" then why is it so hard to ask for, and expect the viewers to be fixed and updated?

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

Michael Emory Cerquoni
I think the big problem is the viewer teams are slow to pickup these changes and fixes, most of the viewer projects seem quite dead to me at the moment, there have been major fixes we have all been waiting quite a very long time for Singularity to do, I cant speak with certainty but this project seems at best to be on pause.  Replex is no longer being updated, Kokua is no longer being updated, I can not say what is really happening with Firestorm as their involvement has always been through what seems to be a high power telescope from very far away.  Most of the other viewers all seem to serve a niche purpose.  We have OnLook viewer now which is designed with the intention of serving only the needs of OpenSimulator and not Second Life, but quite literally no one has volunteered to be involved.  What bothers me about saying get the viewer teams to fix it there is only one response, what viewer teams?  Also if that was the intended goal why was this not coordinated prior to the break, to just go ahead break something and then call it progress while leaving stuff broken and then say oh someone else should fix that is quite unprofessional in any setting.  We need to resolve this problem of viewer development or quite honestly this whole thing is dead in its tracks, without a constantly improving viewer OpenSim is looking more and more like a dead end.  That said its never to late to revive things and start wallking the path to improvement, but as a group we need to stop focusing on the wrong things.   What i see is people chasing ghosts of problems that are not the real core problems of what this project has and needs, with little to zero improvements as a result.  Can anyone name a single improvement that has come from changing the stats?  Where are the patches, where are the scientific write ups showing that this was a success, so far to me this whole thing with stats seems like a big distraction that is not only not beneficial so far, its causing strife between the developers.  Personally I don't have the solutions, my time is very limited anymore and I cant spend the time I have in the past testing things and coordinating people like I have, we need more people to step up and do the right thing without making people feel like its being shoved down their throats.


On Tue, Nov 10, 2015 at 11:48 AM, GarminKawaguichi <[hidden email]> wrote:
I quite agree with what Seth wrote.

GCI


Le 09/11/2015 16:05, Seth Nygard a écrit :
Let the FPS wars begin so there can be confusion everywhere...
Now those that want to can set a ridiculous fudge factor and show 11000000FPS - WOW, look, waaaaaaay faster than "that other grid"!

I firmly disagree in adding anything that allows artificially inflated metrics for any value.  At this stage the configurable fudge factor is an even worse "fix" IMHO.

The correct fix is really to communicate the correct value(s) and put pressure on the viewer developers to fix their lag calculation(s).  People can be expected to update their viewer(s) which is not an unrealistic expectation.  People running old and/or unsupported viewers already have a plethora of issues they need to be aware of and things that don't work right, so why is the lag indicator any different?

If we must have this user configurable then, instead of a fudge factor value it should be a simple boolean setting such as;
ShowArtificiallyInflatedAndIncorrectFPS = false;
ShowArtificiallyInflatedAndIncorrectFPS = true;

On my grid I have made it a point to inform everyone that the calculated lag indicator is broken and the 11FPS is in the correct and normal value.  I also point out that what used to be shown was in fact a falsified and artificially inflated value to make things look like "that other grid".  Most people simple say "Oh yeah, I never paid attention to that anyhow.  It doesn't work right any of the time anyhow".  Many then say they looked at the wiki but couldn't find any information on what to expect.

If whenever people ask for documentation the standard reply from the dev community is "read the code" then why is it so hard to ask for, and expect the viewers to be fixed and updated?

-Seth

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




--
Michael Emory Cerquoni

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

Nicky Perian
>>Kokua is no longer being updated

We work on items for OPENSIM as the come up and for which a
ticket has been files. 

So, if you need something done or added file a ticket.



On Tue, Nov 10, 2015 at 11:06 AM, Michael Emory Cerquoni <[hidden email]> wrote:
I think the big problem is the viewer teams are slow to pickup these changes and fixes, most of the viewer projects seem quite dead to me at the moment, there have been major fixes we have all been waiting quite a very long time for Singularity to do, I cant speak with certainty but this project seems at best to be on pause.  Replex is no longer being updated, Kokua is no longer being updated, I can not say what is really happening with Firestorm as their involvement has always been through what seems to be a high power telescope from very far away.  Most of the other viewers all seem to serve a niche purpose.  We have OnLook viewer now which is designed with the intention of serving only the needs of OpenSimulator and not Second Life, but quite literally no one has volunteered to be involved.  What bothers me about saying get the viewer teams to fix it there is only one response, what viewer teams?  Also if that was the intended goal why was this not coordinated prior to the break, to just go ahead break something and then call it progress while leaving stuff broken and then say oh someone else should fix that is quite unprofessional in any setting.  We need to resolve this problem of viewer development or quite honestly this whole thing is dead in its tracks, without a constantly improving viewer OpenSim is looking more and more like a dead end.  That said its never to late to revive things and start wallking the path to improvement, but as a group we need to stop focusing on the wrong things.   What i see is people chasing ghosts of problems that are not the real core problems of what this project has and needs, with little to zero improvements as a result.  Can anyone name a single improvement that has come from changing the stats?  Where are the patches, where are the scientific write ups showing that this was a success, so far to me this whole thing with stats seems like a big distraction that is not only not beneficial so far, its causing strife between the developers.  Personally I don't have the solutions, my time is very limited anymore and I cant spend the time I have in the past testing things and coordinating people like I have, we need more people to step up and do the right thing without making people feel like its being shoved down their throats.


On Tue, Nov 10, 2015 at 11:48 AM, GarminKawaguichi <[hidden email]> wrote:
I quite agree with what Seth wrote.

GCI


Le 09/11/2015 16:05, Seth Nygard a écrit :
Let the FPS wars begin so there can be confusion everywhere...
Now those that want to can set a ridiculous fudge factor and show 11000000FPS - WOW, look, waaaaaaay faster than "that other grid"!

I firmly disagree in adding anything that allows artificially inflated metrics for any value.  At this stage the configurable fudge factor is an even worse "fix" IMHO.

The correct fix is really to communicate the correct value(s) and put pressure on the viewer developers to fix their lag calculation(s).  People can be expected to update their viewer(s) which is not an unrealistic expectation.  People running old and/or unsupported viewers already have a plethora of issues they need to be aware of and things that don't work right, so why is the lag indicator any different?

If we must have this user configurable then, instead of a fudge factor value it should be a simple boolean setting such as;
ShowArtificiallyInflatedAndIncorrectFPS = false;
ShowArtificiallyInflatedAndIncorrectFPS = true;

On my grid I have made it a point to inform everyone that the calculated lag indicator is broken and the 11FPS is in the correct and normal value.  I also point out that what used to be shown was in fact a falsified and artificially inflated value to make things look like "that other grid".  Most people simple say "Oh yeah, I never paid attention to that anyhow.  It doesn't work right any of the time anyhow".  Many then say they looked at the wiki but couldn't find any information on what to expect.

If whenever people ask for documentation the standard reply from the dev community is "read the code" then why is it so hard to ask for, and expect the viewers to be fixed and updated?

-Seth

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




--
Michael Emory Cerquoni

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

Cinder Roxley
In reply to this post by Michael Emory Cerquoni
On November 10, 2015 at 10:06:24 AM, Michael Emory Cerquoni ([hidden email]) wrote:
I think the big problem is the viewer teams are slow to pickup these changes and fixes, 

They rarely get reported to viewer teams.

most of the viewer projects seem quite dead to me at the moment, there have been major fixes we have all been waiting quite a very long time for Singularity to do, I cant speak with certainty but this project seems at best to be on pause.  

Singularity’s last release was over a year ago. People get busy or move onto other projects more rewarding to them.

Replex is no longer being updated, Kokua is no longer being updated, 

Kokua’s last release was three days ago.

I can not say what is really happening with Firestorm as their involvement has always been through what seems to be a high power telescope from very far away. 

Firestorm still trudges along, but since I left their team, OpenSim support has not only stagnated, but appears to be decaying.

Most of the other viewers all seem to serve a niche purpose.  We have OnLook viewer now which is designed with the intention of serving only the needs of OpenSimulator and not Second Life, but quite literally no one has volunteered to be involved.  What bothers me about saying get the viewer teams to fix it there is only one response, what viewer teams? 

Alchemy stays up to date. We watch the mailing lists. We monitor IRC. I removed the lag meter completely just now. (It’s a bit of a tool for dummies, and the Statistics floater provides developers with better monitoring.) I know Nicky Perian also watches the mailing list and IRC.

Also if that was the intended goal why was this not coordinated prior to the break, to just go ahead break something and then call it progress while leaving stuff broken and then say oh someone else should fix that is quite unprofessional in any setting.  We need to resolve this problem of viewer development or quite honestly this whole thing is dead in its tracks, without a constantly improving viewer OpenSim is looking more and more like a dead end. 

You’ve been saying this for at least two years. Are viewer developers notified when a breaking change is made? No, not unless someone reports it. Are the apis documented? Sort of, but it means slogging through a disorganized wiki and usually digging into OpenSim code too. There isn’t a lot of motivation to jump in and work with no communication and bad documentation especially when those who are actually working on it are blamed for not picking up "changes and fixes” fast enough. Honestly, it’s disheartening to see a six months of effort being discarded as ‘slow’ because nobody will proactively reach out and file a jira or send an e-mail to us. Linden Lab is very good at communicating their needs with us. They have to be. Third party viewers account for the vast majority of their user base.

-- 
Cinder Roxley
Sent with Airmail

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

Michael Emory Cerquoni
Ok thanks for correcting me, I think the biggest problem definitely is communication between the projects, I agree things are very disorganized at this point, a lot of the people did keep things semi organized are all gone at this point onto other projects, i absolutely do not have much time anymore, hence my ignorance to some of the life of these projects, so I do appreciate the correction and am glad to be wrong.  As far as documentation goes I honestly do not know how to address that problem, I would love to get more people to volunteer, but it seems many of the people who use it have no interest in documenting it, can not fully lay the blame at the feet of the developers there.  Unfortunately no one with good organizational skills who has the time and interest has volunteered to lead the charge.   I can only do so much myself and even if I had the time I am not that person, I am spread so thin on this project I might as well not even be here much anymore, id be surprised if any single issue gets even 5% of my time anymore, real life it sucks.   We need someone to step up and be the person, its obvious no one currently involved is that person or wants to be that person or even has the time to be.  So how do we move forward with that, turning this project over to a big controlling entity with Government ties certainly doesn't sound like a good idea to me, I cant really see that making things better, the same could really be said for most big corporations.  So how as a completely open community that takes in zero income, how do we improve that, can we even improve that is the real question. Or is it going to take money and some kind of entity with strict rules and tolerances to control it all.  I can say for sure my interest in opensim as a social tool is waning day by day.  I no longer have the patience to deal with it and still enjoy it anymore in that regard anymore, but I do want to see the technology succeed, but we need to start thinking outside of the Second Life box. or honestly OpenSim is going to disappear as soon as Second Life disappears. Interests are already starting to scatter.

On Tue, Nov 10, 2015 at 1:27 PM, Cinder Roxley <[hidden email]> wrote:
On November 10, 2015 at 10:06:24 AM, Michael Emory Cerquoni ([hidden email]) wrote:
I think the big problem is the viewer teams are slow to pickup these changes and fixes, 

They rarely get reported to viewer teams.

most of the viewer projects seem quite dead to me at the moment, there have been major fixes we have all been waiting quite a very long time for Singularity to do, I cant speak with certainty but this project seems at best to be on pause.  

Singularity’s last release was over a year ago. People get busy or move onto other projects more rewarding to them.

Replex is no longer being updated, Kokua is no longer being updated, 

Kokua’s last release was three days ago.

I can not say what is really happening with Firestorm as their involvement has always been through what seems to be a high power telescope from very far away. 

Firestorm still trudges along, but since I left their team, OpenSim support has not only stagnated, but appears to be decaying.

Most of the other viewers all seem to serve a niche purpose.  We have OnLook viewer now which is designed with the intention of serving only the needs of OpenSimulator and not Second Life, but quite literally no one has volunteered to be involved.  What bothers me about saying get the viewer teams to fix it there is only one response, what viewer teams? 

Alchemy stays up to date. We watch the mailing lists. We monitor IRC. I removed the lag meter completely just now. (It’s a bit of a tool for dummies, and the Statistics floater provides developers with better monitoring.) I know Nicky Perian also watches the mailing list and IRC.

Also if that was the intended goal why was this not coordinated prior to the break, to just go ahead break something and then call it progress while leaving stuff broken and then say oh someone else should fix that is quite unprofessional in any setting.  We need to resolve this problem of viewer development or quite honestly this whole thing is dead in its tracks, without a constantly improving viewer OpenSim is looking more and more like a dead end. 

You’ve been saying this for at least two years. Are viewer developers notified when a breaking change is made? No, not unless someone reports it. Are the apis documented? Sort of, but it means slogging through a disorganized wiki and usually digging into OpenSim code too. There isn’t a lot of motivation to jump in and work with no communication and bad documentation especially when those who are actually working on it are blamed for not picking up "changes and fixes” fast enough. Honestly, it’s disheartening to see a six months of effort being discarded as ‘slow’ because nobody will proactively reach out and file a jira or send an e-mail to us. Linden Lab is very good at communicating their needs with us. They have to be. Third party viewers account for the vast majority of their user base.

-- 
Cinder Roxley
Sent with Airmail

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




--
Michael Emory Cerquoni

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

Michael Emory Cerquoni
and Cinder I did not mean to imply the viewer teams are the problem either, I do apologize if that is how it came off.  I am not trying to shift blame.  I completely agree with you infact, especially in this case with the stats, where the viewer teams were never informed, that is certainly not you or any viewer developers fault.  Really what i mean is there is not always parity between viewer teams in terms of what is and isnt implemented, eventually things balance out, but there tends to be big windows of uncertainty is all.  I am squarely pointing all fingers at the OpenSimulator project right now.

On Tue, Nov 10, 2015 at 1:43 PM, Michael Emory Cerquoni <[hidden email]> wrote:
Ok thanks for correcting me, I think the biggest problem definitely is communication between the projects, I agree things are very disorganized at this point, a lot of the people did keep things semi organized are all gone at this point onto other projects, i absolutely do not have much time anymore, hence my ignorance to some of the life of these projects, so I do appreciate the correction and am glad to be wrong.  As far as documentation goes I honestly do not know how to address that problem, I would love to get more people to volunteer, but it seems many of the people who use it have no interest in documenting it, can not fully lay the blame at the feet of the developers there.  Unfortunately no one with good organizational skills who has the time and interest has volunteered to lead the charge.   I can only do so much myself and even if I had the time I am not that person, I am spread so thin on this project I might as well not even be here much anymore, id be surprised if any single issue gets even 5% of my time anymore, real life it sucks.   We need someone to step up and be the person, its obvious no one currently involved is that person or wants to be that person or even has the time to be.  So how do we move forward with that, turning this project over to a big controlling entity with Government ties certainly doesn't sound like a good idea to me, I cant really see that making things better, the same could really be said for most big corporations.  So how as a completely open community that takes in zero income, how do we improve that, can we even improve that is the real question. Or is it going to take money and some kind of entity with strict rules and tolerances to control it all.  I can say for sure my interest in opensim as a social tool is waning day by day.  I no longer have the patience to deal with it and still enjoy it anymore in that regard anymore, but I do want to see the technology succeed, but we need to start thinking outside of the Second Life box. or honestly OpenSim is going to disappear as soon as Second Life disappears. Interests are already starting to scatter.

On Tue, Nov 10, 2015 at 1:27 PM, Cinder Roxley <[hidden email]> wrote:
On November 10, 2015 at 10:06:24 AM, Michael Emory Cerquoni ([hidden email]) wrote:
I think the big problem is the viewer teams are slow to pickup these changes and fixes, 

They rarely get reported to viewer teams.

most of the viewer projects seem quite dead to me at the moment, there have been major fixes we have all been waiting quite a very long time for Singularity to do, I cant speak with certainty but this project seems at best to be on pause.  

Singularity’s last release was over a year ago. People get busy or move onto other projects more rewarding to them.

Replex is no longer being updated, Kokua is no longer being updated, 

Kokua’s last release was three days ago.

I can not say what is really happening with Firestorm as their involvement has always been through what seems to be a high power telescope from very far away. 

Firestorm still trudges along, but since I left their team, OpenSim support has not only stagnated, but appears to be decaying.

Most of the other viewers all seem to serve a niche purpose.  We have OnLook viewer now which is designed with the intention of serving only the needs of OpenSimulator and not Second Life, but quite literally no one has volunteered to be involved.  What bothers me about saying get the viewer teams to fix it there is only one response, what viewer teams? 

Alchemy stays up to date. We watch the mailing lists. We monitor IRC. I removed the lag meter completely just now. (It’s a bit of a tool for dummies, and the Statistics floater provides developers with better monitoring.) I know Nicky Perian also watches the mailing list and IRC.

Also if that was the intended goal why was this not coordinated prior to the break, to just go ahead break something and then call it progress while leaving stuff broken and then say oh someone else should fix that is quite unprofessional in any setting.  We need to resolve this problem of viewer development or quite honestly this whole thing is dead in its tracks, without a constantly improving viewer OpenSim is looking more and more like a dead end. 

You’ve been saying this for at least two years. Are viewer developers notified when a breaking change is made? No, not unless someone reports it. Are the apis documented? Sort of, but it means slogging through a disorganized wiki and usually digging into OpenSim code too. There isn’t a lot of motivation to jump in and work with no communication and bad documentation especially when those who are actually working on it are blamed for not picking up "changes and fixes” fast enough. Honestly, it’s disheartening to see a six months of effort being discarded as ‘slow’ because nobody will proactively reach out and file a jira or send an e-mail to us. Linden Lab is very good at communicating their needs with us. They have to be. Third party viewers account for the vast majority of their user base.

-- 
Cinder Roxley
Sent with Airmail

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




--
Michael Emory Cerquoni



--
Michael Emory Cerquoni

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

Cinder Roxley
On November 10, 2015 at 11:54:29 AM, Michael Emory Cerquoni ([hidden email]) wrote:
and Cinder I did not mean to imply the viewer teams are the problem either, I do apologize if that is how it came off.  I am not trying to shift blame.  I completely agree with you infact, especially in this case with the stats, where the viewer teams were never informed, that is certainly not you or any viewer developers fault.  Really what i mean is there is not always parity between viewer teams in terms of what is and isnt implemented, eventually things balance out, but there tends to be big windows of uncertainty is all.  I am squarely pointing all fingers at the OpenSimulator project right now.

Thanks. It is worrisome to see Singularity winding down because they seemed to be the de facto canonical viewer since Imprudence stopped. I’ve tried sending patches to Firestorm myself and encouraging them to move to Alchemy’s OpenSim base, but not had much success in doing so.

Talked with Diva some months ago about moving to a more modular client-server model for the viewer and break away from conventional Second Life architecture and design patterns. I think that’s going to be the only way to outlive Second Life, by becoming a more expansive-use platform than SL ever did.

-- 
Cinder Roxley
Sent with Airmail

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

Ai Austin-2
In reply to this post by Seth Nygard
Michael Emory Cerquoni (Nebadon2015) wrote:
>I think the big problem is the viewer teams are slow to pickup these
>changes and fixes, most of the viewer projects seem quite dead to me at the
>moment...

I cannot agree at all Neb... as you have seen from Cinder, Nicky and
others, I have found that OpenSim issues raised on the viewer issue
trackers are VERY quickly discussed and often directly between
interested OpenSim devs and those looking at OpenSim aspects of the viewers.

I am a Firestorm (SL+OS version) user myself mostly but also for
testing and specialised use Singularity, Alchemy, Kokoa,
CtrlAltStudio (a Firestorm variant for 3D stereo and Oculus) as I use
a lot of different grids and Second Life. Just as one example of all
the viewer developments, for those watching the Firestorm commits and
issue tracker it is extremely active... and although their approach
is to have quite a long time between releases there is a LOT of
testing and feedback with beta testing groups and pre release
candidates for those signing up to the groups that test those.  The
next Firestorm 4.7.5 for example has been in active testing for some
time and reached a Release Candidate stage in the last few days.

I do try to raise issues or add comments on the Firestorm JIRA to
raise coordination issues, cross posting Firestorm JIRA and OpenSim
Mantis issues between them, and I have found they are addressed,
commented on or looked at almost instantly.  I would encourage
everyone else interested in any specific viewer to do that.  Its the
key way viewer folks can get to know what is happening in
OpenSim-land, though quite a few of the viewer devs of course also
track or contribute to OpenSim.

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

Michael Emory Cerquoni
Great Austin I do not expect everyone to agree with me, surely I cant be 100% correct, but things feel very scattered to me, and while most things do get addressed quickly we find on OSgrid epsecially there to be a lot of disparity between viewers and it makes for a very disjointed experience, we also cant expect everyone to run the latest viewer, some people are just not savy enough to download and install updates every few weeks or even understand why they have to until someone explains it to them and helps them through it.    I work with a lot of people who have never used Second Life and no experience with the viewers and I can tell you there is a lot of disjointed experiences, and consistancy is not always a factor for me when having to train people and realize we all have different viewers and versions and even if we both have singularity things might not be the same because this person has a version from last year.  The Whole experience seems tailored to experts or at best people who consider theirselves gamers, but i also find most gamers do not find this kind of environment very interesting.  We really need to rethink the concept of the viewer beyond just a fixed never changing portal that looks very very different depending on what viewer the person who is trying to convince you to use the world has suggested.  We need a viewer interface that can be consistantly programmed from the server side, so everyone can atleast have a similar basic set of functions/huds and have a much better overall first experience.  My point is TPV cant just be bug fixing, we need to expand functionality and make the viewer do things that SL can not.  Otherwise we are just SL and when the whole world gets bored of SL, they are also going to get bored with OpenSim.

On Tue, Nov 10, 2015 at 2:52 PM, Ai Austin <[hidden email]> wrote:
Michael Emory Cerquoni (Nebadon2015) wrote:
I think the big problem is the viewer teams are slow to pickup these
changes and fixes, most of the viewer projects seem quite dead to me at the
moment...

I cannot agree at all Neb... as you have seen from Cinder, Nicky and others, I have found that OpenSim issues raised on the viewer issue trackers are VERY quickly discussed and often directly between interested OpenSim devs and those looking at OpenSim aspects of the viewers.

I am a Firestorm (SL+OS version) user myself mostly but also for testing and specialised use Singularity, Alchemy, Kokoa, CtrlAltStudio (a Firestorm variant for 3D stereo and Oculus) as I use a lot of different grids and Second Life. Just as one example of all the viewer developments, for those watching the Firestorm commits and issue tracker it is extremely active... and although their approach is to have quite a long time between releases there is a LOT of testing and feedback with beta testing groups and pre release candidates for those signing up to the groups that test those.  The next Firestorm 4.7.5 for example has been in active testing for some time and reached a Release Candidate stage in the last few days.

I do try to raise issues or add comments on the Firestorm JIRA to raise coordination issues, cross posting Firestorm JIRA and OpenSim Mantis issues between them, and I have found they are addressed, commented on or looked at almost instantly.  I would encourage everyone else interested in any specific viewer to do that.  Its the key way viewer folks can get to know what is happening in OpenSim-land, though quite a few of the viewer devs of course also track or contribute to OpenSim.


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



--
Michael Emory Cerquoni

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

Ai Austin-2
In reply to this post by Seth Nygard
Very much agreed on those points Neb...  that's my experience too
with a wide user base... some experienced and many not... and some
just entering for the first time or just needing to quickly join for
an experience or meeting. I am all for active development.

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

Myron Curtis
In reply to this post by Michael Emory Cerquoni

Let’s face it. What we really need is a viewer that is embedded in a webserver with the configurability of a Word Press site so that anyone with any web enabled device can have access to a world, and the grid owners can both brand and configure it to meet the needs of their specific clientele. Who better to develop that but the viewer teams and the core teams working together?

Myron

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Emory Cerquoni
Sent: Tuesday, November 10, 2015 12:02 PM
To: [hidden email]
Subject: Re: [Opensim-dev] Still on Sim and Phys Frames per Second (FPS)

 

Great Austin I do not expect everyone to agree with me, surely I cant be 100% correct, but things feel very scattered to me, and while most things do get addressed quickly we find on OSgrid epsecially there to be a lot of disparity between viewers and it makes for a very disjointed experience, we also cant expect everyone to run the latest viewer, some people are just not savy enough to download and install updates every few weeks or even understand why they have to until someone explains it to them and helps them through it.    I work with a lot of people who have never used Second Life and no experience with the viewers and I can tell you there is a lot of disjointed experiences, and consistancy is not always a factor for me when having to train people and realize we all have different viewers and versions and even if we both have singularity things might not be the same because this person has a version from last year.  The Whole experience seems tailored to experts or at best people who consider theirselves gamers, but i also find most gamers do not find this kind of environment very interesting.  We really need to rethink the concept of the viewer beyond just a fixed never changing portal that looks very very different depending on what viewer the person who is trying to convince you to use the world has suggested.  We need a viewer interface that can be consistantly programmed from the server side, so everyone can atleast have a similar basic set of functions/huds and have a much better overall first experience.  My point is TPV cant just be bug fixing, we need to expand functionality and make the viewer do things that SL can not.  Otherwise we are just SL and when the whole world gets bored of SL, they are also going to get bored with OpenSim.

 

On Tue, Nov 10, 2015 at 2:52 PM, Ai Austin <[hidden email]> wrote:

Michael Emory Cerquoni (Nebadon2015) wrote:

I think the big problem is the viewer teams are slow to pickup these
changes and fixes, most of the viewer projects seem quite dead to me at the
moment...


I cannot agree at all Neb... as you have seen from Cinder, Nicky and others, I have found that OpenSim issues raised on the viewer issue trackers are VERY quickly discussed and often directly between interested OpenSim devs and those looking at OpenSim aspects of the viewers.

I am a Firestorm (SL+OS version) user myself mostly but also for testing and specialised use Singularity, Alchemy, Kokoa, CtrlAltStudio (a Firestorm variant for 3D stereo and Oculus) as I use a lot of different grids and Second Life. Just as one example of all the viewer developments, for those watching the Firestorm commits and issue tracker it is extremely active... and although their approach is to have quite a long time between releases there is a LOT of testing and feedback with beta testing groups and pre release candidates for those signing up to the groups that test those.  The next Firestorm 4.7.5 for example has been in active testing for some time and reached a Release Candidate stage in the last few days.

I do try to raise issues or add comments on the Firestorm JIRA to raise coordination issues, cross posting Firestorm JIRA and OpenSim Mantis issues between them, and I have found they are addressed, commented on or looked at almost instantly.  I would encourage everyone else interested in any specific viewer to do that.  Its the key way viewer folks can get to know what is happening in OpenSim-land, though quite a few of the viewer devs of course also track or contribute to OpenSim.



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




--

Michael Emory Cerquoni


_______________________________________________
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
In reply to this post by Seth Nygard

On Tue, Nov 10, 2015 at 9:06 AM, Michael Emory Cerquoni <[hidden email]> wrote:
.....  Also if that was the intended goal why was this not coordinated prior to the break, to just go ahead break something and then call it progress while leaving stuff broken and then say oh someone else should fix that is quite unprofessional in any setting.  We need to resolve this problem of viewer development or quite honestly this whole thing is dead in its tracks, without a constantly improving viewer OpenSim is looking more and more like a dead end.  That said its never to late to revive things and start wallking the path to improvement, but as a group we need to stop focusing on the wrong things.  

HUH???     Coordinated???    An independent  group of developers  who WANT OpenSim to work  used the appropriate  forum  to ask everyone about the cause,  and  asked for suggestions on how to correct the problem...    A patch was generated  and went through  3 months of iterations  and  VERY open discussion..   The  whole point of that  was to notify the people who participate and garner feedback from anyone/everyone  in the community.    The  FACT is   there was general agreement  among  most of  CORE  and the  other  participants  that THIS WAS a step forward.   I cant  find  anywhere in any of these early discussions  where anyone expressed the unprofessional attitude you assert.   

 
What i see is people chasing ghosts of problems that are not the real core problems of what this project has and needs, with little to zero improvements as a result.  Can anyone name a single improvement that has come from changing the stats?  Where are the patches, where are the scientific write ups showing that this was a success, so far to me this whole thing with stats seems like a big distraction that is not only not beneficial so far, its causing strife between the developers. 

Chasing  Ghosts??   really,   you don't want to go there  AT ALL...  WHERE is the road map of the REAL CORE PROBLEMS???   How many times  have  people stood  and said  I'm ready, willing, and able to help,  Please tell me  what I should focus on?  If you want to look for a failure of communication  I suggest you start there before you start blaming the folks  who have followed the  very public lead of core  and picked a problem that is important to them! 

Where are the papers??   The  consensus of the participants in the discussion  was that the  made up numbers  were impacting the credibility of those  who were already publishing.  It is  also  extremely misleading  to categorize  MOSES as the only  group interested in conducting these  performance measurement/improvement tests and  publishing  results... Maybe  you should review  some of  Christas'  publications,,  or the serious gaming PhD thesis whose  author  bothered to speak up in favor,   Or maybe  you just forget the years of Intel projects???   If you actually  READ the  communications from MOSES  you would understand  that they  could NOT publish  results  of  all the previously testing  knowing that the results  were inaccurate. 

 
Personally I don't have the solutions, my time is very limited anymore and I cant spend the time I have in the past testing things and coordinating people like I have, we need more people to step up and do the right thing without making people feel like its being shoved down their throats.


AMEN!     We do need  people to step up...    and a bunch of us  did.   We were  publicly ridiculed  ( and that ridicule  continues. )    We jumped through ALL the  hoops,   we  communicated  with everyone  we were told needed to be involved,    MOSES  reworked, and resubmitted  patches.   They spent the time to attempt to communicate  WHY this was an important step forward.   We welcomed the discussion..  and  honestly  until the other day   It seemed like it was a success...      All of a sudden,  In the space of  3 days,  we are  informed  that some  mysterious  user  has  whispered their annoyance about an OBSOLETE feature in one of the viewers , and because of this  "comment" our efforts  would be  ignored in favor  of  a solution proposed and implemented in the "backroom".      Who is shoving  what down  whose throat?

The community  has spoken on the issue of incorrect performance measurement figures being reported  and agreed it IS a step forward.  The fact is,  Melanie  could have added her solution to the code base on her grid in minutes  and could have  avoided this discussion  altogether.  There is  NO REASON  why her fix  needed  to be included in core. Her assertion  that "someone  else  can  recode the stats  to use a new method of reporting " is arrogant  and ignores the fact  that it is the most complex  solution to implement... (sound  familiar to the unprofessional attitude  you attributed  elsewhere??)  She has demanded that the  PHYSICS  FPS reporting field already provided in the viewer  be populated  with FALSE data and seems to think it is reasonable that MOSES  repeat the tortuous affair  to re-code  ANOTHER solution and  go through the process of  convincing her it is technically correct.     Please   just ask yourself....  How inclusive is that??  Why would anyone  who saw any of this  step forward and volunteer   to do what members of core have been  pushing folks to do  since  2009?

THAT,   pure and simple,  is the reason  we cannot  get people interested in continuing to work  with the project...   That is  not to say  that the work won't continue  ON the project,  it  will just continue to be done  in splintered efforts  by people  who are  basically  fed up with dealing  with this  disregard  for the people  who make the effort to participate in this forum.   

Just  so I am clear...  I AM NOT a member of the MOSES development  group..   but I am a supporter of their efforts..   Outside of the time I spent with Intel on the  Science Sim grid,  they are the most  dedicated, competent, and forward looking of the development groups  interested in OpenSim I have had the pleasure to work with.   In my opinion,,  if core cant  extend a hand  and figure out a way to work with this group,  they are carving a BIG  R.I.P. on the tombstone of  OpenSim as we know it...   MOSES  will build a simulator that dramatically improves the  physics  capabilities and performance,  They are likely to be the first to implement  an HTML based  viewer,  and (If we are lucky)   they will  implement a scheme of  distributed simulator services  that will integrate with the future of cloud based apps.  I am proud to be allowed to participate in their efforts,   and , at the moment   totally embarrassed  by how this project has reacted to them.

Doug Osborn


_______________________________________________
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
Please refrain from spreading falsehoods about me. I have NEVER
advocated to touch the physics FPS field at all, not in the initial
discussion and not in this one!

I have advocated to ADD A NEW STAT in some way, so the numeric
display can be accurate while still allowing the lag meter to work.

Since then, after looking into the packet and it's data, I have
pointed to TWO feasible solutions to the problem.

Also, this is not even about Avination. Avination has never stopped
reporting 55 FPS because Avination is a commercial grid and we want
to give our users a positive experience, correctness of stats has
never been Avination's concern.

However, I spoke out in support of the change to correct values
because I was unaware that the viewer used that value for anything
other than display, else I would have spoken out against the change
from the start and presented my alternatives then.

If, however, your intent is just to attack me personally, then
please go to the end of the line. There is a long queue already.

- Melanie

On 10/11/2015 23:48, dz wrote:

> On Tue, Nov 10, 2015 at 9:06 AM, Michael Emory Cerquoni <
> [hidden email]> wrote:
>
>> .....  Also if that was the intended goal why was this not coordinated
>> prior to the break, to just go ahead break something and then call it
>> progress while leaving stuff broken and then say oh someone else should fix
>> that is quite unprofessional in any setting.  We need to resolve this
>> problem of viewer development or quite honestly this whole thing is dead in
>> its tracks, without a constantly improving viewer OpenSim is looking more
>> and more like a dead end.  That said its never to late to revive things and
>> start wallking the path to improvement, but as a group we need to stop
>> focusing on the wrong things.
>>
>
> HUH???     Coordinated???    An independent  group of developers  who WANT
> OpenSim to work  used the appropriate  forum  to ask everyone about the
> cause,  and  asked for suggestions on how to correct the problem...    A
> patch was generated  and went through  3 months of iterations  and  VERY
> open discussion..   The  whole point of that  was to notify the people who
> participate and garner feedback from anyone/everyone  in the community.
>  The  FACT is   there was general agreement  among  most of  CORE  and the
>  other  participants  that THIS WAS a step forward.   I cant  find
>  anywhere in any of these early discussions  where anyone expressed the
> unprofessional attitude you assert.
>
>
>
>> What i see is people chasing ghosts of problems that are not the real core
>> problems of what this project has and needs, with little to zero
>> improvements as a result.  Can anyone name a single improvement that has
>> come from changing the stats?  Where are the patches, where are the
>> scientific write ups showing that this was a success, so far to me this
>> whole thing with stats seems like a big distraction that is not only not
>> beneficial so far, its causing strife between the developers.
>>
>
> Chasing  Ghosts??   really,   you don't want to go there  AT ALL...  WHERE
> is the road map of the REAL CORE PROBLEMS???   How many times  have  people
> stood  and said  I'm ready, willing, and able to help,  Please tell me
>  what I should focus on?  If you want to look for a failure of
> communication  I suggest you start there before you start blaming the folks
>  who have followed the  very public lead of core  and picked a problem that
> is important to them!
>
> Where are the papers??   The  consensus of the participants in the
> discussion  was that the  made up numbers  were impacting the credibility
> of those  who were already publishing.  It is  also  extremely misleading
>  to categorize  MOSES as the only  group interested in conducting these
>  performance measurement/improvement tests and  publishing  results...
> Maybe  you should review  some of  Christas'  publications,,  or the
> serious gaming PhD thesis whose  author  bothered to speak up in favor,
> Or maybe  you just forget the years of Intel projects???   If you actually
>  READ the  communications from MOSES  you would understand  that they
>  could NOT publish  results  of  all the previously testing  knowing that
> the results  were inaccurate.
>
>
>
>> Personally I don't have the solutions, my time is very limited anymore and
>> I cant spend the time I have in the past testing things and coordinating
>> people like I have, we need more people to step up and do the right thing
>> without making people feel like its being shoved down their throats.
>>
>>
> AMEN!     We do need  people to step up...    and a bunch of us  did.   We
> were  publicly ridiculed  ( and that ridicule  continues. )    We jumped
> through ALL the  hoops,   we  communicated  with everyone  we were told
> needed to be involved,    MOSES  reworked, and resubmitted  patches.   They
> spent the time to attempt to communicate  WHY this was an important step
> forward.   We welcomed the discussion..  and  honestly  until the other day
>   It seemed like it was a success...      All of a sudden,  In the space of
>  3 days,  we are  informed  that some  mysterious  user  has  whispered
> their annoyance about an OBSOLETE feature in one of the viewers , and
> because of this  "comment" our efforts  would be  ignored in favor  of  a
> solution proposed and implemented in the "backroom".      Who is shoving
>  what down  whose throat?
>
> The community  has spoken on the issue of incorrect performance measurement
> figures being reported  and agreed it IS a step forward.  The fact is,
>  Melanie  could have added her solution to the code base on her grid in
> minutes  and could have  avoided this discussion  altogether.  There is  NO
> REASON  why her fix  needed  to be included in core. Her assertion  that
> "someone  else  can  recode the stats  to use a new method of reporting "
> is arrogant  and ignores the fact  that it is the most complex  solution to
> implement... (sound  familiar to the unprofessional attitude  you
> attributed  elsewhere??)  She has demanded that the  PHYSICS  FPS reporting
> field already provided in the viewer  be populated  with FALSE data and
> seems to think it is reasonable that MOSES  repeat the tortuous affair  to
> re-code  ANOTHER solution and  go through the process of  convincing her it
> is technically correct.     Please   just ask yourself....  How inclusive
> is that??  Why would anyone  who saw any of this  step forward and
> volunteer   to do what members of core have been  pushing folks to do
>  since  2009?
>
> THAT,   pure and simple,  is the reason  we cannot  get people interested
> in continuing to work  with the project...   That is  not to say  that the
> work won't continue  ON the project,  it  will just continue to be done  in
> splintered efforts  by people  who are  basically  fed up with dealing
>  with this  disregard  for the people  who make the effort to participate
> in this forum.
>
> Just  so I am clear...  I AM NOT a member of the MOSES development  group..
>   but I am a supporter of their efforts..   Outside of the time I spent
> with Intel on the  Science Sim grid,  they are the most  dedicated,
> competent, and forward looking of the development groups  interested in
> OpenSim I have had the pleasure to work with.   In my opinion,,  if core
> cant  extend a hand  and figure out a way to work with this group,  they
> are carving a BIG  R.I.P. on the tombstone of  OpenSim as we know it...
> MOSES  will build a simulator that dramatically improves the  physics
>  capabilities and performance,  They are likely to be the first to
> implement  an HTML based  viewer,  and (If we are lucky)   they will
>  implement a scheme of  distributed simulator services  that will integrate
> with the future of cloud based apps.  I am proud to be allowed to
> participate in their efforts,   and , at the moment   totally embarrassed
>  by how this project has reacted to them.
>
> Doug Osborn
>
>
>
>
> _______________________________________________
> 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
1234
Loading...