<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
DigiWorldz and Great Canadian Grid are running the newer code with
stats reporting 11fps without issue.<br>
When we first made the change, we let everyone know and we've never
yet 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 is made aware of the changes and the reasons, I don't think
there would be any issues.<br>
<br>
I am a fan of the Architect Frank Lloyd Wright and I remember
reading a story about him once... <br>
Someone had complained to him that his design on one of his builds
was very poor and it was leaking water each time it rained... his
reply... grab a bucket and catch the water.<br>
While his build looked awesome, it had an obvious flaw, but instead
of addressing it, he indicated using a bucket to catch the water
would fix 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>
<div class="moz-cite-prefix">On 11/9/2015 12:31 PM, Zadark Portal
wrote:<br>
</div>
<blockquote
cite="mid:CABorpp2MLaMscjhW2+fhWwCMr=Ve8UtfSrdW+qTNtmRkgmqv-Q@mail.gmail.com"
type="cite">
<div dir="ltr">+1 dz
<div><br>
</div>
<div>I cannot add to the well informed technical reasonings
already contributed.<br>
<div><br>
</div>
<div>But, the suggested amendment is purely cosmetic. I fail
to understand why grid operators are persistently unable to
portray the importance of accurate measurements to their
clients.</div>
<div><br>
</div>
<div>Of equal concern is perpetuating a culture where non
evidence based observations prevail within the user
community only to be dismissed by equally subjective
reasoning.</div>
<div><br>
</div>
<div>+1 dz (again)</div>
<div><br>
</div>
<div>Z </div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 9 November 2015 at 16:37, Maxwell,
Douglas CIV USARMY RDECOM ARL (US) <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:douglas.maxwell3.civ@mail.mil"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:douglas.maxwell3.civ@mail.mil">douglas.maxwell3.civ@mail.mil</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">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 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 intense<br>
troubleshooting on the OpenSimulator to try to find where
instabilities and<br>
performance enhancements can make most sense. Pandering to
the users by<br>
artificially inflating the numbers does no one any good and
is quite frankly,<br>
weak sauce. I'm sorry the lag meters don't work anymore,
but that is the<br>
consequence of improperly reporting the stats in the first
place. 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 three major<br>
components of the CORE that need work to improve stability
and scalability.<br>
We (MOSES) are testing the new PhysX addition and could not
do our jobs<br>
without proper stats reporting. In fact, months of work (and
money) was wasted<br>
last year when we attempted to address physics issues and
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 and will<br>
hopefully yield a workable architecture to allow dozens of
people to log in<br>
simultaneously without lag or impact on the rest of the
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, 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) <a moz-do-not-send="true"
href="tel:%28407%29%20242-0209" value="+14072420209">(407)
242-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>]
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>
Subject: [Non-DoD Source] Re: [Opensim-dev] Still on Sim and
Phys Frames per<br>
Second (FPS)<br>
<br>
All active links contained in this email were disabled.
Please verify the<br>
identity of the sender, and confirm the authenticity of all
links contained<br>
within the message prior to copying and pasting the address
to a Web browser.<br>
<br>
<br>
________________________________<br>
<br>
<br>
<br>
The issue is promoting accurate reporting of basic
performance measurement<br>
statistics. ( something that has not achieved nearly
enough serious<br>
attention )<br>
<br>
Significant money and manpower is currently being directed
at efforts to<br>
improve simulator performance.<br>
It is a simple fact that the continued funding of these
efforts relies on<br>
documenting the ACTUAL improvement against the ACTUAL
original performance<br>
characteristics.<br>
It is impossible to justify these efforts when the reported
numbers are<br>
"made up" and THAT fact is not documented except in some
obscure comment<br>
left behind in the source code.<br>
<br>
<br>
It is unfortunate that the original decision to include a
"Fudge factor<br>
multiplier" has created a pool of mis-informed users (
including myself and<br>
the viewer developers ) .<br>
This mistake was complicated by the fact that until very
recently there was a<br>
philosophical divide that prevented OpenSim and viewer
developers from<br>
cooperating on issues like these.<br>
This decision to "play pretend" with performance stats
effectively damaged the<br>
reporting credibility of everyone who published these
inaccurate results,<br>
It also created a rift between the OpenSim and viewer
developers over the<br>
decision to NOT discuss the impact of implementing the
change. The fact<br>
is, there are numerous places in the OpenSim framework
where numbers are<br>
"made up" just so that a number appears in performance
reports. That an<br>
effort is being made to correct those sources of
mis-information should be<br>
welcomed.<br>
<br>
<br>
It seems to me that the decisions made by core should be
made in favor of<br>
supporting the ongoing efforts to accurately document and
improve simulator<br>
performance.<br>
Justin realized this and lead many of the efforts to add
some measurement<br>
metrics. Even with those efforts, we still cannot
measure basic<br>
statistics like Events per Second sent to the script engine,
or tie those<br>
events to whatever script is handling them. This makes
identifying the<br>
scripts ACTUALLY responsible for "lagging" a region
impossible 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
managers to add<br>
back the Fudge Factor to appease their vocal users, but
would disagree that<br>
the PROPER decision should be to continue to report
inaccurate results. It<br>
would be just as easy to implement a multiplier in the
viewer code "Lag<br>
Meter", This would also allow the accurate reporting of
statistics in the<br>
Advanced Statistics window and administrative reporting.
I believe it was<br>
also one of the suggested resolutions put forth by the
viewer developers... It<br>
should be clear to anyone who has spent time in world that
the "lag meter" is<br>
incorrect... You can walk, build, chat and TP with the
same level of sim<br>
performance as you could before the numbers were changed.
We've overlooked<br>
the fact that viewers have behaved differently in OpenSim
and "that other<br>
grid" for years. Why is it "all of a sudden" CRITICAL
that this one<br>
viewer feature HAS to be the same? In these days when
core developers<br>
are releasing viewers, I cannot understand the urgency of
accommodating a<br>
minor feature of one viewer whose developers have already
demonstrated a<br>
willingness to work with OpenSim to tailor a configuration
to meet 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>
Caution-mailto:<a moz-do-not-send="true"
href="mailto:melanie@t-data.com">melanie@t-data.com</a>
> > wrote:<br>
<br>
<br>
The issue here is the so-called "lag meter". Since
removal 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
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. OpenSim now<br>
always reports a lesser value. This is damaging and
needs 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 original decision to<br>
> report values closely matching "the other
grid", IMHO doing so created<br>
> an incorrect understanding in many users' minds
of how things work<br>
> and/or behave. We are not that other grid and
should never pretend to<br>
> be. Had figures been reported correctly in the
beginning then there<br>
> would be no confusion now surrounding this
subject. However avoiding<br>
> confusion is a poor reason to roll back and
once again report the<br>
> artificially inflated values. It is better to
simply educate and make<br>
> it clear that the value of 11fps is indeed the
correct value to expect,<br>
> and is in fact the true value things always
have ran at despite what any<br>
> inflated reported value said.<br>
><br>
> It is true that many scripts and tools have
already been written to use<br>
> the inflated values but they can all be changed
with relative ease. The<br>
> viewers already have many aspects that are
different for Open Simulator<br>
> so they can be changed easily as well for new
versions also with<br>
> relative ease. All we need to do as a
community is establish what the<br>
> correct and expected values are and then
document and communicate them.<br>
><br>
> As a user, scripter, tool developer, and grid
manager, I for one want to<br>
> see true and accurate values for any and all
metrics regardless of where<br>
> they are shown or how they may be used. I
therefore am 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>
Caution-mailto:<a moz-do-not-send="true"
href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a>
><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>
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>
Opensim-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a>
< Caution-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>
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>
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><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>
</blockquote>
</div>
<br>
</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>