<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I think for sake of accuracy we should leave it by default to report
correctly.<br>
For those who do not want the accurate results and prefer to use the
multiplied values, give them an option in the ini file to set
StatsFudgeFactorOn = true or something similar.<br>
Doing this would satisfy both sides without any further discussion
and would then allow the grid/region operator the option to run it
they way they prefer as it should be.<br>
<br>
~Terry<br>
<br>
<div class="moz-cite-prefix">On 11/9/2015 12:52 PM, Michael Emory
Cerquoni wrote:<br>
</div>
<blockquote
cite="mid:CAF5=rqW=WPqtkh-Heh8qaD4hu9ZpLHLVAgTjpHudVa4nApwfbQ@mail.gmail.com"
type="cite">
<p dir="ltr">Personally i think we should have left the fudge
factor stats alone and introduced new non multiplied stats.
Forcing everyone to change because one single project has a goal
is not great. If the projects goal is to do back end analysis
who cares what we send to the viewer.</p>
<div class="gmail_quote">On Nov 9, 2015 9:48 AM, "Melanie" <<a
moz-do-not-send="true" href="mailto:melanie@t-data.com"><a class="moz-txt-link-abbreviated" href="mailto:melanie@t-data.com">melanie@t-data.com</a></a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Viewers WILL
have to change but something like the "Lag Meter" does<br>
depend on some way of generating a normalized value.<br>
<br>
This can either be done by normalizing to a standard frame of<br>
reference, most often 0.0 .. 1.0 is used for this, or
normalizing to<br>
a known value, e.g. 55 fps.<br>
<br>
In the absence of a normalized value, viewers would not be
able to<br>
calculate the lag meter unless the stats packet also contains
a<br>
value telling the viewer what "normal" is. This is currently
not the<br>
case.<br>
<br>
With sim stats being a UDP packet, we really can't add fields
easily<br>
without breaking with the SL standard and all viewers strive
to not<br>
only work in OpenSim but also in SL.<br>
<br>
One could possibly add the "normal" value to the
SimulatorFeatures<br>
cap, since it is not expected that that value would or could
change<br>
while clients are logged in. That still would require viewers
to<br>
change and viewers are slow to change.<br>
<br>
Sadly, things required only by OpenSim are incorporated much
less<br>
speedily than things required for continued SL compatibility.
We<br>
should therefore strive to provide what is needed for the
viewers to<br>
adapt but some of us are not in a position to leave the
current<br>
users out in the rain.<br>
<br>
- Melanie<br>
<br>
On 09/11/2015 18:40, Terry Ford wrote:<br>
> DigiWorldz and Great Canadian Grid are running the newer
code with stats<br>
> reporting 11fps without issue.<br>
> When we first made the change, we let everyone know and
we've never yet<br>
> had any complaints about it.<br>
> I've not seen any issues regarding the change on my end
so far.<br>
><br>
> I personally prefer the corrected stats and I think as
long as everyone<br>
> is made aware of the changes and the reasons, I don't
think there would<br>
> be any issues.<br>
><br>
> I am a fan of the Architect Frank Lloyd Wright and I
remember reading a<br>
> story about him once...<br>
> Someone had complained to him that his design on one of
his builds was<br>
> very poor and it was leaking water each time it rained...
his reply...<br>
> grab a bucket and catch the water.<br>
> While his build looked awesome, it had an obvious flaw,
but instead of<br>
> addressing it, he indicated using a bucket to catch the
water would fix<br>
> the issue.<br>
> Isn't that what we are essentially doing here... grabbing
buckets?<br>
> I personally prefer a roof which doesn't leak.<br>
><br>
> ~Terry<br>
><br>
><br>
><br>
> On 11/9/2015 12:31 PM, Zadark Portal wrote:<br>
>> +1 dz<br>
>><br>
>> I cannot add to the well informed technical
reasonings already<br>
>> contributed.<br>
>><br>
>> But, the suggested amendment is purely cosmetic. I
fail to understand<br>
>> why grid operators are persistently unable to portray
the importance<br>
>> of accurate measurements to their clients.<br>
>><br>
>> Of equal concern is perpetuating a culture where non
evidence based<br>
>> observations prevail within the user community only
to be dismissed by<br>
>> equally subjective reasoning.<br>
>><br>
>> +1 dz (again)<br>
>><br>
>> Z<br>
>><br>
>> On 9 November 2015 at 16:37, Maxwell, Douglas CIV
USARMY RDECOM ARL<br>
>> (US) <<a moz-do-not-send="true"
href="mailto:douglas.maxwell3.civ@mail.mil">douglas.maxwell3.civ@mail.mil</a><br>
>> <mailto:<a moz-do-not-send="true"
href="mailto:douglas.maxwell3.civ@mail.mil">douglas.maxwell3.civ@mail.mil</a>>>
wrote:<br>
>><br>
>> Classification: UNCLASSIFIED<br>
>> Caveats: NONE<br>
>><br>
>> +1 dz<br>
>><br>
>> I'm not trying to start a flame war, so pls take
these comments as<br>
>> my own<br>
>> opinion.<br>
>><br>
>> To be honest, I don't understand how the
counter-argument to accurate<br>
>> reporting could possibly be taken seriously. We
have done some<br>
>> intense<br>
>> troubleshooting on the OpenSimulator to try to
find where<br>
>> instabilities and<br>
>> performance enhancements can make most sense.
Pandering to the<br>
>> users by<br>
>> artificially inflating the numbers does no one
any good and is<br>
>> quite frankly,<br>
>> weak sauce. I'm sorry the lag meters don't work
anymore, but that<br>
>> is the<br>
>> consequence of improperly reporting the stats in
the first place.<br>
>> The correct<br>
>> fix here isn't to re-break stats reporting.<br>
>><br>
>> Secondly, I don't understand how the Devs plan(!)
to address the<br>
>> three major<br>
>> components of the CORE that need work to improve
stability and<br>
>> scalability.<br>
>> We (MOSES) are testing the new PhysX addition and
could not do our<br>
>> jobs<br>
>> without proper stats reporting. In fact, months
of work (and<br>
>> money) was wasted<br>
>> last year when we attempted to address physics
issues and<br>
>> profiling only to<br>
>> find out we couldn't trust the data we were
collecting!<br>
>><br>
>> Our next work will involve addressing the client
manager issues<br>
>> and will<br>
>> hopefully yield a workable architecture to allow
dozens of people<br>
>> to log in<br>
>> simultaneously without lag or impact on the rest
of the<br>
>> simulator. Again,<br>
>> can't do this without proper stats reporting.<br>
>><br>
>> Think of this as a MacOSX moment. Might break
some old things,<br>
>> but in the end<br>
>> you will be better for it.<br>
>><br>
>> v/r -doug<br>
>><br>
>> Douglas Maxwell, Ph.D.<br>
>> Science and Technology Manager<br>
>> Virtual World Strategic Applications<br>
>> U.S. Army Research Lab<br>
>> Simulation & Training Technology Center
(STTC)<br>
>> (c) (407) 242-0209
<a class="moz-txt-link-rfc2396E" href="tel:%28407%29%20242-0209"><tel:%28407%29%20242-0209></a><br>
>><br>
>><br>
>><br>
>> -----Original Message-----<br>
>> From: <a moz-do-not-send="true"
href="mailto:opensim-dev-bounces@opensimulator.org">opensim-dev-bounces@opensimulator.org</a><br>
>> <mailto:<a moz-do-not-send="true"
href="mailto:opensim-dev-bounces@opensimulator.org">opensim-dev-bounces@opensimulator.org</a>><br>
>> [mailto:<a moz-do-not-send="true"
href="mailto:opensim-dev-bounces@opensimulator.org">opensim-dev-bounces@opensimulator.org</a><br>
>> <mailto:<a moz-do-not-send="true"
href="mailto:opensim-dev-bounces@opensimulator.org">opensim-dev-bounces@opensimulator.org</a>>]
On Behalf Of dz<br>
>> Sent: Saturday, November 07, 2015 8:54 PM<br>
>> To: <a moz-do-not-send="true"
href="mailto:opensim-dev@opensimulator.org">opensim-dev@opensimulator.org</a><br>
>> <mailto:<a moz-do-not-send="true"
href="mailto:opensim-dev@opensimulator.org">opensim-dev@opensimulator.org</a>><br>
>> Subject: [Non-DoD Source] Re: [Opensim-dev] Still
on Sim and Phys<br>
>> Frames per<br>
>> Second (FPS)<br>
>><br>
>> All active links contained in this email were
disabled. Please<br>
>> verify the<br>
>> identity of the sender, and confirm the
authenticity of all links<br>
>> contained<br>
>> within the message prior to copying and pasting
the address to a<br>
>> Web browser.<br>
>><br>
>><br>
>> ________________________________<br>
>><br>
>><br>
>><br>
>> The issue is promoting accurate reporting of
basic performance<br>
>> measurement<br>
>> statistics. ( something that has not achieved
nearly enough<br>
>> serious<br>
>> attention )<br>
>><br>
>> Significant money and manpower is currently being
directed at<br>
>> efforts to<br>
>> improve simulator performance.<br>
>> It is a simple fact that the continued funding of
these efforts<br>
>> relies on<br>
>> documenting the ACTUAL improvement against the
ACTUAL original<br>
>> performance<br>
>> characteristics.<br>
>> It is impossible to justify these efforts when
the reported<br>
>> numbers are<br>
>> "made up" and THAT fact is not documented
except in some obscure<br>
>> comment<br>
>> left behind in the source code.<br>
>><br>
>><br>
>> It is unfortunate that the original decision to
include a "Fudge<br>
>> factor<br>
>> multiplier" has created a pool of mis-informed
users ( including<br>
>> myself and<br>
>> the viewer developers ) .<br>
>> This mistake was complicated by the fact that
until very recently<br>
>> there was a<br>
>> philosophical divide that prevented OpenSim and
viewer developers<br>
>> from<br>
>> cooperating on issues like these.<br>
>> This decision to "play pretend" with performance
stats effectively<br>
>> damaged the<br>
>> reporting credibility of everyone who published
these<br>
>> inaccurate results,<br>
>> It also created a rift between the OpenSim and
viewer developers<br>
>> over the<br>
>> decision to NOT discuss the impact of
implementing the change.<br>
>> The fact<br>
>> is, there are numerous places in the OpenSim
framework where<br>
>> numbers are<br>
>> "made up" just so that a number appears in
performance reports.<br>
>> That an<br>
>> effort is being made to correct those sources of
mis-information<br>
>> should be<br>
>> welcomed.<br>
>><br>
>><br>
>> It seems to me that the decisions made by core
should be made in<br>
>> favor of<br>
>> supporting the ongoing efforts to accurately
document and improve<br>
>> simulator<br>
>> performance.<br>
>> Justin realized this and lead many of the
efforts to add some<br>
>> measurement<br>
>> metrics. Even with those efforts, we still
cannot measure basic<br>
>> statistics like Events per Second sent to the
script engine, or<br>
>> tie those<br>
>> events to whatever script is handling them. This
makes<br>
>> identifying the<br>
>> scripts ACTUALLY responsible for "lagging" a
region impossible<br>
>> using the<br>
>> traditional TOP SCRIPTS report in region manager
window.<br>
>><br>
>> I would agree that a simple solution might be to
allow grid<br>
>> managers to add<br>
>> back the Fudge Factor to appease their vocal
users, but would<br>
>> disagree that<br>
>> the PROPER decision should be to continue to
report inaccurate<br>
>> results. It<br>
>> would be just as easy to implement a
multiplier in the viewer<br>
>> code "Lag<br>
>> Meter", This would also allow the accurate
reporting of<br>
>> statistics in the<br>
>> Advanced Statistics window and administrative
reporting. I<br>
>> believe it was<br>
>> also one of the suggested resolutions put forth
by the viewer<br>
>> developers... It<br>
>> should be clear to anyone who has spent time in
world that the<br>
>> "lag meter" is<br>
>> incorrect... You can walk, build, chat and TP
with the same<br>
>> level of sim<br>
>> performance as you could before the numbers
were changed. We've<br>
>> overlooked<br>
>> the fact that viewers have behaved differently
in OpenSim and<br>
>> "that other<br>
>> grid" for years. Why is it "all of a sudden"
CRITICAL that<br>
>> this one<br>
>> viewer feature HAS to be the same? In these
days when core<br>
>> developers<br>
>> are releasing viewers, I cannot understand the
urgency of<br>
>> accommodating a<br>
>> minor feature of one viewer whose developers
have already<br>
>> demonstrated a<br>
>> willingness to work with OpenSim to tailor a
configuration to meet<br>
>> our needs.<br>
>><br>
>><br>
>><br>
>> On Sat, Nov 7, 2015 at 1:19 PM, Melanie <<a
moz-do-not-send="true" href="mailto:melanie@t-data.com"><a class="moz-txt-link-abbreviated" href="mailto:melanie@t-data.com">melanie@t-data.com</a></a><br>
>> <mailto:<a moz-do-not-send="true"
href="mailto:melanie@t-data.com">melanie@t-data.com</a>>
<<br>
>> Caution-mailto:<a moz-do-not-send="true"
href="mailto:melanie@t-data.com">melanie@t-data.com</a>
<mailto:<a moz-do-not-send="true"
href="mailto:melanie@t-data.com">melanie@t-data.com</a>>
> ><br>
>> wrote:<br>
>><br>
>><br>
>> The issue here is the so-called "lag
meter". Since removal<br>
>> of the<br>
>> multiplier, this reports all opensim
regions as laggy, without<br>
>> exception. Users' trust in the "lag
meter" is damaging OpenSim<br>
>> reputation. This is not a value that is
merely for<br>
>> display; the<br>
>> viewer uses this value for computations
that are then used to<br>
>> "judge" a sim to be "laggy" if it's below
35 or so fps.<br>
>> OpenSim now<br>
>> always reports a lesser value. This is
damaging and needs<br>
>> to be made<br>
>> configurable and by default match the
viewer's expectations.<br>
>><br>
>> - Melanie<br>
>><br>
>><br>
>> On 07/11/2015 16:38, Seth Nygard wrote:<br>
>> > While I understand the arguments
surrounding the<br>
>> original decision to<br>
>> > report values closely matching "the
other grid", IMHO<br>
>> doing so created<br>
>> > an incorrect understanding in many
users' minds of how<br>
>> things work<br>
>> > and/or behave. We are not that
other grid and should<br>
>> never pretend to<br>
>> > be. Had figures been reported
correctly in the<br>
>> beginning then there<br>
>> > would be no confusion now
surrounding this subject.<br>
>> However avoiding<br>
>> > confusion is a poor reason to roll
back and once again<br>
>> report the<br>
>> > artificially inflated values. It
is better to simply<br>
>> educate and make<br>
>> > it clear that the value of 11fps is
indeed the correct<br>
>> value to expect,<br>
>> > and is in fact the true value things
always have ran at<br>
>> despite what any<br>
>> > inflated reported value said.<br>
>> ><br>
>> > It is true that many scripts and
tools have already been<br>
>> written to use<br>
>> > the inflated values but they can all
be changed with<br>
>> relative ease. The<br>
>> > viewers already have many aspects
that are different for<br>
>> Open Simulator<br>
>> > so they can be changed easily as
well for new versions<br>
>> also with<br>
>> > relative ease. All we need to do as
a community is<br>
>> establish what the<br>
>> > correct and expected values are and
then document and<br>
>> communicate them.<br>
>> ><br>
>> > As a user, scripter, tool developer,
and grid manager, I<br>
>> for one want to<br>
>> > see true and accurate values for any
and all metrics<br>
>> regardless of where<br>
>> > they are shown or how they may be
used. I therefore am<br>
>> firmly against<br>
>> > rolling back to any older
artificially inflated values.<br>
>> ><br>
>> > Regards<br>
>> > -Seth<br>
>> ><br>
>> ><br>
>> >
_______________________________________________<br>
>> > Opensim-dev mailing list<br>
>> > <a moz-do-not-send="true"
href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
>> <mailto:<a moz-do-not-send="true"
href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a>>
<<br>
>> Caution-mailto:<a moz-do-not-send="true"
href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
>> <mailto:<a moz-do-not-send="true"
href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a>>
><br>
>> ><br>
>> Caution-<a moz-do-not-send="true"
href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev"
rel="noreferrer" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
>> <<br>
>> Caution-<a moz-do-not-send="true"
href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev"
rel="noreferrer" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
>> ><br>
>><br>
>>
_______________________________________________<br>
>> Opensim-dev mailing list<br>
>> <a moz-do-not-send="true"
href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
>> <mailto:<a moz-do-not-send="true"
href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a>>
<<br>
>> Caution-mailto:<a moz-do-not-send="true"
href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
>> <mailto:<a moz-do-not-send="true"
href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a>><br>
>> ><br>
>><br>
>> Caution-<a moz-do-not-send="true"
href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev"
rel="noreferrer" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
>> <<br>
>> Caution-<a moz-do-not-send="true"
href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev"
rel="noreferrer" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
>> ><br>
>><br>
>><br>
>><br>
>><br>
>> Classification: UNCLASSIFIED<br>
>> Caveats: NONE<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Opensim-dev mailing list<br>
>> <a moz-do-not-send="true"
href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a>
<mailto:<a moz-do-not-send="true"
href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a>><br>
>> <a moz-do-not-send="true"
href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev"
rel="noreferrer" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Opensim-dev mailing list<br>
>> <a moz-do-not-send="true"
href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
>> <a moz-do-not-send="true"
href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev"
rel="noreferrer" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a moz-do-not-send="true"
href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
> <a moz-do-not-send="true"
href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev"
rel="noreferrer" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
<a moz-do-not-send="true"
href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev"
rel="noreferrer" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Opensim-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a>
<a class="moz-txt-link-freetext" href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a>
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
---------------------<br>
<b>Terry Ford</b><br>
DigiWorldz Grid<br>
<a class="moz-txt-link-freetext" href="http://digiworldz.com">http://digiworldz.com</a></div>
</body>
</html>