[Opensim-dev] Sim and Phys Frames per Second (FPS) Issues (UNCLASSIFIED)

Wed Mar 4 14:53:55 UTC 2015

Classification: UNCLASSIFIED
Caveats: NONE

This is a great link, thank you for passing it along.  I'll add it to my
tutorial toolbox for the interns.  For those of you interested in another
HTML5 based system, the Virtual World Framework is also a simple design to
understand.

https://virtual.wf/

v/r -douglas

Douglas Maxwell, MSME
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 Diva Canto
Sent: Tuesday, March 03, 2015 9:55 AM
To: opensim-dev at opensimulator.org
Subject: Re: [Opensim-dev] Sim and Phys Frames per Second (FPS) Issues

Again, for people interested in learning more about these design issues, and
the tradeoffs of different choices, I highly recommend this tutorial and
associated code:
http://buildnewgames.com/real-time-multiplayer/

It's a wonderful little example that explains how interactive multi-user
client-server simulations work. 100x simpler than OpenSim, but essentially
the same concepts. It doesn't explain time dilation, but it's not hard to
see where that comes in: in varying the time window of the physics loop. The
update (simulation) loop is mainly about notifying clients about changes in
the state of the simulation. We want the physics simulation to be high
fidelity (meaning high loop rate), and the client updates to be as low as
possible (low update loop rate).  

On 3/3/2015 2:09 AM, Tom Bess wrote:

	Thanks. You have clarified much. I realised the rift is viewer
control but was not so clear about the impact/relationship between viewer
and server frame rates  and the interpolation needed.

	Thanks again.

	Tom Willans  BSc(Hons)  MBCS  CITP 
	Chartered IT Professional

	Managing Director Bessacarr Publications Ltd
	+44 (0)121 288 0281
	email: tom.willans at bessacarr.com
	skype: tom.willans
	Second Life and OSGrid: Tom Tiros 

	Sent from my mobile

	On 3 Mar 2015, at 09:08, Dahlia Trimble <dahliatrimble at gmail.com>
wrote:

		If my memory is correct, SL sims run at a default of 45
frames/second. OpenSimulator runs at 11. I'm not certain exactly why 11 was
chosen but I do know that increasing it increases the amount of work the
simulator must do. E.g., if you go from 11 to 45 you quadruple the work the
simulator must do

		The only signal I'm aware of that affects the viewer is
"time dilation". This value varies from 0.0 to 1.0 where 1.0 indicates the
simulator is running at full speed. If for some reason the physics engine
cannot keep up with the simulation it can signal the viewers to slow
movement. This value is sent with many UDP packets that are involved with
the scene and moving objects, so the viewers will know this value as timely
as possible.

		Running the simulation at 11 fps shoudl *not* affect devices
such as the Rift as the camera is controlled entirely viewer side except
under special circumstances such as a user surrendering camera control to a
script. The viewer frame rate is *entirely independent* of the simulator
frame rate and will run as fast as the hardware allows if configured to do
so.

		Choosing an appropriate simulation frame rate would involve
weighing the tradeoffs between simulation workload and responsiveness to
user controls such as those that control avatar position movement. Bear in
mind that there are also network delays involved; a simulation running at 11
frames/second will respond to a user control every 89 ms but there will also
be round-trip network delays which may typically be 100-200 ms but as high
as 1.5 seconds or more. Increashing the simulation frame rate will likely
not produce a perceivable difference in performance but will *significantly
reduce* the capacity of the simulator to do things like host more avatars
and scripted objects.

		Also bear in mind that much of the code assumes 11
frames/second and raising that may create motion-related and other bugs that
may not be apparent until much later. OpenSimulator is tuned to function
properly at 11 frames/second.

		To recap: the user camera is for the most part entirely
controlled within the viewer and is unaffected by simulation frame rate. As
such devices such as the Rift which manipulate the camera will not be
affected.

		On Tue, Mar 3, 2015 at 12:09 AM, Tom Bess
<tom.willans at bessacarr.com> wrote:

			I am reporting a comparison between sl and opensim
and did not realise this. Does sl run at a true 55fps? If so why bother?
Presumably the viewer needs 55fps sent to it to get its calculations correct
as at 11fps opensim does the same at sl albeit in larger steps. 

			Would a faster fps improve the accuracy of devices
such as the rift by having to interpolate over a shorter period of time?
Admittedly I suspect viewer rendering needs to be improved as well as this
aspect is holding my experience back. 

			I understand that other aspects may assume that
11fps is a fixed constant and not allow for this to change presumably that
can be changed but you guys know more here.

			Thanks for the guide btw. 

			Tom Willans  BSc(Hons)  MBCS  CITP 
			Chartered IT Professional

			Managing Director Bessacarr Publications Ltd
			+44 (0)121 288 0281
<tel:%2B44%20%280%29121%20288%200281> 
			email: tom.willans at bessacarr.com
			skype: tom.willans
			Second Life and OSGrid: Tom Tiros 

			Sent from my mobile

			On 3 Mar 2015, at 05:18, Sean M
<mondesire.sean at gmail.com> wrote:

				Thanks Justin, Dahlia, Michael, and
everyone. I now have a better understanding of the way FPS is calculated and
of the correction factor.  

				-Sean M. 

				On Monday, March 2, 2015, Justin Clark-Casey
<jjustincc at googlemail.com> wrote:

					I think this has already been said
but just to summarize.

					* The 11 fps are the number of scene
frames processed - opportunities where avatars may be notified about changes
in the scene.

					* Each of these scene frames is
associated with a physics process where 5 physics frames are processed in
each frame. Hence 11 * 5 = 55 fps.

					* Why this number?  Others may know
better but my guess is that it's related to the frequency of updates
expected by the viewer.  Teravus may well know more if he's still around.

					* Changing
m_reportedFpsCorrectionFactor will do nothing except change the server FPS
stat.

					* Changing MinFrameTime will change
the number of scene frames.  From my work in the past, you would also need
to adjust other parameters like physics frames to stop things going haywire
(this was with ODE, Bullet might work differently).  I expect you also
wouldn't gain much if anything in scene fidelity.

					On 02/03/15 18:23, Sean M wrote:

						Greetings,

						We at the MOSES project have
noticed Simulation and Physics frames per second (FPS) have a few issues
that we are trying
						to resolve. The issues are
producing suspicious performance statistics for the analysis of the current
version of
						OpenSim that we are running.

						First, there is a correction
factor (m_reportedFpsCorrectionFactor) that the raw SimFPS is multiplied by.
The comment in
						the following line is a bit
curious because it indicates that the FPS is artificially inflated to "lie"
about the actual
						FPS being so low:

OpenSim/Region/Framework/__Scenes/SimStatsReporter.cs: Line 317
						// We're going to lie about
the FPS because we've been lying since 2008.  The actual FPS is currently
						// locked at a maximum of
11.  Maybe at some point this can change so that we're not lying.
						int reportedFPS =
(int)(m_fps * m_reportedFpsCorrectionFactor);

						Also, lines 174 and 227
mention the use of this correction factor.

						Second, this multiplier also
comes into play in the Scene where there is a MinFrameTime, which seems to
be the minimum
						reported amount of time to
process a frame:

OpenSim/Region/Framework/__Scenes/Scene.cs:Line 723

						Both of these variables, the
correction factor and MinFrameTime, are concerning from a statistics view
point as they are
						generating skewed and
massaged numbers; therefore, I have a few questions:

						1) Is it commonly known that
Sim and Phy FPSs are inflated to maintain the "lie"? And if so, will it be
corrected to be
						an accurate reporting of
processed frames per second?

						2) What exactly are the
definitions for OpenSim's Simulation (Sim) FPS, Physics (Phy) FPS and a
frame (I have found
						conflicting and vague
definitions on the wiki)?

						3) What are the known
performance consequences of setting the m_reportedFpsCorrectionFactor to 1
and MinFrameTime to 0?

						Thanks,
						Sean M.

_______________________________________________
						Opensim-dev mailing list

Opensim-dev at opensimulator.org

http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

					-- 
					Justin Clark-Casey (justincc)
					OSVW Consulting
					http://justincc.org
					http://twitter.com/justincc

_______________________________________________
					Opensim-dev mailing list
					Opensim-dev at opensimulator.org

http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

_______________________________________________
				Opensim-dev mailing list
				Opensim-dev at opensimulator.org

http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

			_______________________________________________
			Opensim-dev mailing list
			Opensim-dev at opensimulator.org

http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

		_______________________________________________
		Opensim-dev mailing list
		Opensim-dev at opensimulator.org

http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

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

Classification: UNCLASSIFIED
Caveats: NONE

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5629 bytes
Desc: not available
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20150304/4a96937f/attachment.bin>