[Opensim-dev] Still on Sim and Phys Frames per Second (FPS)
Jak Daniels
jak at ateb.co.uk
Mon Nov 9 16:26:07 UTC 2015
+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, opensim-dev-request at opensimulator.org wrote:
>>> Send Opensim-dev mailing list submissions to
>>> opensim-dev at opensimulator.org
>>>
>>> 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
>>> opensim-dev-request at opensimulator.org
>>>
>>> You can reach the person managing the list at
>>> opensim-dev-owner at opensimulator.org
>>>
>>> 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 <melanie at t-data.com>
>>> To: "opensim-dev at opensimulator.org" <opensim-dev at opensimulator.org>
>>> Subject: Re: [Opensim-dev] Still on Sim and Phys Frames per Second
>>> (FPS)
>>> Message-ID: <925ECFD1-AF4F-42EE-A1F7-806717665871 at t-data.com>
>>> 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 <dz at bitzend.net> 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 <melanie at t-data.com>
>>> 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 <teravus at gmail.com>
>>> 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 <ajlduarte at sapo.pt> 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: opensim-dev-bounces at opensimulator.org
>>>> [mailto:opensim-dev-bounces at opensimulator.org] On Behalf Of Melanie
>>>> Sent: Sunday, November 08, 2015 02:35
>>>> To: opensim-dev at opensimulator.org
>>>> Subject: Re: [Opensim-dev] Still on Sim and Phys Frames per Second
>>>> (FPS)
>>>>
>>>> There are too many viewers in the wild, having too many users that are
>>>> unwilling to switch or update, yet complain about "lag" which they
>>>> do not
>>>> perceive, but which is indicated by a "lag meter" that is geared to
>>>> measure
>>>> against constants provided by "that grid".
>>>>
>>>> It is a given that the data sent to viewers WILL be changed to
>>>> allow viewer
>>>> features to work properly again. It is also a given that control
>>>> over this
>>>> will be given to users of OpenSim, allowing them to see true
>>>> performance
>>>> data instead of expected data. However, that option can't be the
>>>> default in
>>>> a world where the primary use of OpenSim is to provide a social
>>>> virtual
>>>> world.
>>>>
>>>> I had already suggested and here suggest it again to add more data
>>>> to the
>>>> stats reporting that will track accurate and unfudged data, but
>>>> doesn't do
>>>> so in fields currently interpreted in accordance to SL standards by
>>>> ALL
>>>> mainstream viewers.
>>>>
>>>> This will allow viewers which become aware of the new data to use
>>>> it to
>>>> provide accurate stats and, for instance, make an adaptive "lag
>>>> meter" in
>>>> place of the current, constants driven one.
>>>>
>>>> The situation where viewer report an ERROR CONDITION because of the
>>>> desire
>>>> of some to see "accurate" stats can not be sustained because it
>>>> undermines
>>>> user confidence.
>>>>
>>>> The choices are to accede to user demands while creating a way for
>>>> viewers
>>>> to get "smarter" or to live in a world where the change is
>>>> introduced at
>>>> source code level by grid operators without an adequate correct
>>>> replacement
>>>> stat, therefore locking in the current situation forever.
>>>>
>>>> Please understand that core exists to guide this project in a way that
>>>> allows it's users to work, not in a way that upholds principles
>>>> over people.
>>>>
>>>> - Melanie
>>>>
>>>> On 08/11/2015 02:53, dz wrote:
>>>>> The issue is promoting accurate reporting of basic performance
>>>>> measurement statistics. ( something that has not achieved nearly
>>>>> enough serious attention )
>>>>>
>>>>> Significant money and manpower is currently being directed at efforts
>>>>> to improve simulator performance.
>>>>> It is a simple fact that the continued funding of these efforts
>>>>> relies on documenting the ACTUAL improvement against the ACTUAL
>>>>> original performance characteristics.
>>>>> It is impossible to justify these efforts when the reported numbers
>>>>> are "made up" and THAT fact is not documented except in some
>>>>> obscure comment left behind in the source code.
>>>>>
>>>>> It is unfortunate that the original decision to include a "Fudge
>>>>> factor multiplier" has created a pool of mis-informed users (
>>>>> including
>>>> myself
>>>>> and the viewer developers ) .
>>>>> This mistake was complicated by the fact that until very recently
>>>>> there was a philosophical divide that prevented OpenSim and viewer
>>>>> developers from cooperating on issues like these.
>>>>> This decision to "play pretend" with performance stats effectively
>>>>> damaged the reporting credibility of everyone who published these
>>>>> inaccurate results, It also created a rift between the OpenSim and
>>>>> viewer developers over the decision to NOT discuss the impact of
>>>> implementing the change.
>>>>> The fact is, there are numerous places in the OpenSim framework
>>>>> where numbers are "made up" just so that a number appears in
>>>>> performance reports. That an effort is being made to correct those
>>>>> sources of mis-information should be welcomed.
>>>>>
>>>>> It seems to me that the decisions made by core should be made in
>>>>> favor of supporting the ongoing efforts to accurately document and
>>>>> improve simulator performance.
>>>>> Justin realized this and lead many of the efforts to add some
>>>>> measurement
>>>>> metrics. Even with those efforts, we still cannot measure basic
>>>>> statistics like Events per Second sent to the script engine, or tie
>>>>> those events to whatever script is handling them. This makes
>>>>> identifying the scripts ACTUALLY responsible for "lagging" a region
>>>>> impossible using the traditional TOP SCRIPTS report in region
>>>>> manager
>>>> window.
>>>>> I would agree that a simple solution might be to allow grid managers
>>>>> to add back the Fudge Factor to appease their vocal users, but
>>>>> would
>>>>> disagree that the PROPER decision should be to continue to report
>>>>> inaccurate results. It would be just as easy to implement a
>>>>> multiplier in the viewer code "Lag Meter", This would also allow
>>>>> the accurate reporting of statistics in the Advanced Statistics
>>>>> window and administrative reporting. I believe it was also one of
>>>>> the suggested resolutions put forth by the viewer developers... It
>>>>> should be clear to anyone who has spent time in world that the "lag
>>>> meter" is incorrect...
>>>>> You can walk, build, chat and TP with the same level of sim
>>>>> performance as you could before the numbers were changed. We've
>>>>> overlooked the fact that viewers have behaved differently in
>>>>> OpenSim and
>>>> "that other grid"
>>>>> for years. Why is it "all of a sudden" CRITICAL that this one
>>>> viewer
>>>>> feature HAS to be the same? In these days when core
>>>>> developers are
>>>>> releasing viewers, I cannot understand the urgency of
>>>>> accommodating a
>>>>> minor feature of one viewer whose developers have already
>>>>> demonstrated a willingness to work with OpenSim to tailor a
>>>>> configuration to meet our needs.
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Nov 7, 2015 at 1:19 PM, Melanie <melanie at t-data.com> wrote:
>>>>>
>>>>>> The issue here is the so-called "lag meter". Since removal of the
>>>>>> multiplier, this reports all opensim regions as laggy, without
>>>>>> exception. Users' trust in the "lag meter" is damaging OpenSim
>>>>>> reputation. This is not a value that is merely for display; the
>>>>>> viewer uses this value for computations that are then used to
>>>>>> "judge"
>>>>>> a sim to be "laggy" if it's below 35 or so fps. OpenSim now always
>>>>>> reports a lesser value. This is damaging and needs to be made
>>>>>> configurable and by default match the viewer's expectations.
>>>>>>
>>>>>> - Melanie
>>>>>>
>>>>>> On 07/11/2015 16:38, Seth Nygard wrote:
>>>>>>> While I understand the arguments surrounding the original decision
>>>>>>> to report values closely matching "the other grid", IMHO doing so
>>>>>>> created an incorrect understanding in many users' minds of how
>>>>>>> things work and/or behave. We are not that other grid and should
>>>>>>> never pretend to be. Had figures been reported correctly in the
>>>>>>> beginning then there would be no confusion now surrounding this
>>>>>>> subject. However avoiding confusion is a poor reason to roll
>>>>>>> back and
>>>> once again report the
>>>>>>> artificially inflated values. It is better to simply educate and
>>>>>>> make
>>>>>>> it clear that the value of 11fps is indeed the correct value to
>>>>>>> expect, and is in fact the true value things always have ran at
>>>>>>> despite what any inflated reported value said.
>>>>>>>
>>>>>>> It is true that many scripts and tools have already been written to
>>>>>>> use the inflated values but they can all be changed with relative
>>>>>>> ease. The viewers already have many aspects that are different for
>>>>>>> Open Simulator so they can be changed easily as well for new
>>>>>>> versions also with relative ease. All we need to do as a community
>>>>>>> is establish what the correct and expected values are and then
>>>>>>> document
>>>> and communicate them.
>>>>>>> As a user, scripter, tool developer, and grid manager, I for one
>>>>>>> want to see true and accurate values for any and all metrics
>>>>>>> regardless of where they are shown or how they may be used. I
>>>>>>> therefore am firmly against rolling back to any older artificially
>>>> inflated values.
>>>>>>> Regards
>>>>>>> -Seth
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Opensim-dev mailing list
>>>>>>> Opensim-dev at opensimulator.org
>>>>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>>>> _______________________________________________
>>>>>> Opensim-dev mailing list
>>>>>> Opensim-dev at opensimulator.org
>>>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Opensim-dev mailing list
>>>>> Opensim-dev at opensimulator.org
>>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>> _______________________________________________
>>>> Opensim-dev mailing list
>>>> Opensim-dev at opensimulator.org
>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>>
>>>> _______________________________________________
>>>> Opensim-dev mailing list
>>>> Opensim-dev at opensimulator.org
>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at opensimulator.org
>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL:
>>> <http://opensimulator.org/pipermail/opensim-dev/attachments/20151109/594b6922/attachment.html>
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at opensimulator.org
>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>
>>>
>>> End of Opensim-dev Digest, Vol 20, Issue 17
>>> *******************************************
>>
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at opensimulator.org
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
> --
> ---------------------
> *Terry Ford*
> DigiWorldz Grid
> http://digiworldz.com
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org
> 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/4aef7252/attachment-0001.html>
More information about the Opensim-dev
mailing list