[Opensim-dev] [Non-DoD Source] Re: Still on Sim and Phys Frames per Second (FPS) (UNCLASSIFIED)

AJLDuarte ajlduarte at sapo.pt
Mon Nov 9 21:03:41 UTC 2015


Hi doug,
	No flames assumed.
	I tried to explain within my limited English skills, my understanding of the nature of the issue on OpenSim. Melanie and others expressed it better possible.
	About the use of the statistics sent to viewers as profiling tools. Guess it is not necessary to mention that we do know about the scaling factor and have a idea of reliability of some parameters and even know the ones still totally broken.
	For more complete profile the short answer is: we don’t use them.
	
	Our current code already contributions that did result from detailed profiling with goals similar to yours. As example amongst others, I can remember the work done by Intel teams. The article starting at
https://software.intel.com/en-us/articles/opensimulator-virtual-world-server-case-study-part-1
By Robert Adams, (that you already know as a member of our team) is just a small expression what they did.

This just to mention one organization with well defined work methodologies like yours.

Meanwhile we will try to fake very accurately.

Regards,
Leal Duarte(Ubit Umarov)
	

-----Original Message-----
From: opensim-dev-bounces at opensimulator.org [mailto:opensim-dev-bounces at opensimulator.org] On Behalf Of Maxwell, Douglas CIV USARMY RDECOM ARL (US)
Sent: Monday, November 09, 2015 16:37
To: opensim-dev at opensimulator.org
Subject: Re: [Opensim-dev] [Non-DoD Source] Re: Still on Sim and Phys Frames per Second (FPS) (UNCLASSIFIED)

Classification: UNCLASSIFIED
Caveats: NONE

+1 dz

I'm not trying to start a flame war, so pls take these comments as my own opinion.

To be honest, I don't understand how the counter-argument to accurate reporting could possibly be taken seriously.  We have done some intense troubleshooting on the OpenSimulator to try to find where instabilities and performance enhancements can make most sense.  Pandering to the users by artificially inflating the numbers does no one any good and is quite frankly, weak sauce.  I'm sorry the lag meters don't work anymore, but that is the consequence of improperly reporting the stats in the first place.  The correct fix here isn't to re-break stats reporting.

Secondly, I don't understand how the Devs plan(!) to address the three major components of the CORE that need work to improve stability and scalability. 
We (MOSES) are testing the new PhysX addition and could not do our jobs without proper stats reporting. In fact, months of work (and money) was wasted last year when we attempted to address physics issues and profiling only to find out we couldn't trust the data we were collecting!

Our next work will involve addressing the client manager issues and will hopefully yield a workable architecture to allow dozens of people to log in simultaneously without lag or impact on the rest of the simulator.  Again, can't do this without proper stats reporting.

Think of this as a MacOSX moment.  Might break some old things, but in the end you will be better for it.

v/r -doug

Douglas Maxwell, Ph.D.
Science and Technology Manager
Virtual World Strategic Applications
U.S. Army Research Lab
Simulation & Training Technology Center (STTC)
(c) (407) 242-0209



-----Original Message-----
From: opensim-dev-bounces at opensimulator.org
[mailto:opensim-dev-bounces at opensimulator.org] On Behalf Of dz
Sent: Saturday, November 07, 2015 8:54 PM
To: opensim-dev at opensimulator.org
Subject: [Non-DoD Source] Re: [Opensim-dev] Still on Sim and Phys Frames per Second (FPS)

All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser.


________________________________



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 < Caution-mailto: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 < 
Caution-mailto:Opensim-dev at opensimulator.org >
	> Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev < 
Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >

	_______________________________________________
	Opensim-dev mailing list
	Opensim-dev at opensimulator.org < Caution-mailto:Opensim-dev at opensimulator.org 
 >
	Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev < 
Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >




Classification: UNCLASSIFIED
Caveats: NONE





More information about the Opensim-dev mailing list