<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 href="mailto:melanie@t-data.com">melanie@t-data.com</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 href="mailto:douglas.maxwell3.civ@mail.mil">douglas.maxwell3.civ@mail.mil</a><br>
>> <mailto:<a 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 <tel:%28407%29%20242-0209><br>
>><br>
>><br>
>><br>
>> -----Original Message-----<br>
>> From: <a href="mailto:opensim-dev-bounces@opensimulator.org">opensim-dev-bounces@opensimulator.org</a><br>
>> <mailto:<a href="mailto:opensim-dev-bounces@opensimulator.org">opensim-dev-bounces@opensimulator.org</a>><br>
>> [mailto:<a href="mailto:opensim-dev-bounces@opensimulator.org">opensim-dev-bounces@opensimulator.org</a><br>
>> <mailto:<a 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 href="mailto:opensim-dev@opensimulator.org">opensim-dev@opensimulator.org</a><br>
>> <mailto:<a 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 href="mailto:melanie@t-data.com">melanie@t-data.com</a><br>
>> <mailto:<a href="mailto:melanie@t-data.com">melanie@t-data.com</a>> <<br>
>> Caution-mailto:<a href="mailto:melanie@t-data.com">melanie@t-data.com</a> <mailto:<a 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 href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
>> <mailto:<a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a>> <<br>
>> Caution-mailto:<a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
>> <mailto:<a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a>> ><br>
>> ><br>
>> Caution-<a 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 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 href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
>> <mailto:<a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a>> <<br>
>> Caution-mailto:<a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
>> <mailto:<a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a>><br>
>> ><br>
>><br>
>> Caution-<a 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 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 href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a> <mailto:<a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a>><br>
>> <a 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 href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
>> <a 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 href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
> <a 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 href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
<a 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>