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, [email protected] wrote:
Send Opensim-dev mailing list submissions to
[email protected]
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
[email protected]
You can reach the person managing the list at
[email protected]
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 <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [Opensim-dev] Still on Sim and Phys Frames per Second
(FPS)
Message-ID: <[email protected]>
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 <[email protected]> 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 <[email protected]>
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 <[email protected]>
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 <[email protected]> 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: [email protected]
[mailto:[email protected]] On Behalf Of Melanie
Sent: Sunday, November 08, 2015 02:35
To: [email protected]
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 <[email protected]> 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
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
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
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
End of Opensim-dev Digest, Vol 20, Issue 17
*******************************************
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
