[Opensim-dev] Still on Sim and Phys Frames per Second (FPS)
Shy Robbiani
shy.robbiani at gmail.com
Tue Nov 10 16:13:41 UTC 2015
+1 too. I totally agree with anything said by Seth.
On Mon, Nov 9, 2015 at 5:26 PM, Jak Daniels <jak at ateb.co.uk> 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, 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> <melanie at t-data.com>
> To: "opensim-dev at opensimulator.org" <opensim-dev at opensimulator.org>
> <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>
> <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> <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> <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> <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>
> <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
> <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>
> <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>
> <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 listOpensim-dev at opensimulator.orghttp://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/20151110/db750f9f/attachment-0001.html>
More information about the Opensim-dev
mailing list