[Opensim-dev] Sim and Phys Frames per Second (FPS) Issues (UNCLASSIFIED)
Maxwell, Douglas CIV USARMY ARL (US)
douglas.maxwell3.civ at mail.mil
Tue Mar 3 14:25:11 UTC 2015
Classification: UNCLASSIFIED
Caveats: NONE
Thank you all for your input and clarification on this issue. We are not
interested in changing the frame rate, only to understand it so that we may
profile correctly. We are looking at how much time the simulator spends
processing each actor under different load profiles. We are also performing
statistical analyses to look for anomalies, such as time spent in the script
actor when there are no scripts running in the sim.
This is all very valuable information and we appreciate your assistance.
Don't be surprised if you see a patch from us that corrects the misreporting
of the simulator frame rate very soon. We need to perform some testing to see
how the client will react to the changes.
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 Tom Bess
Sent: Tuesday, March 03, 2015 5:10 AM
To: opensim-dev at opensimulator.org
Subject: Re: [Opensim-dev] Sim and Phys Frames per Second (FPS) Issues
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 <blockedtel:%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
<blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>
--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org <blockedhttp://justincc.org>
http://twitter.com/justincc <blockedhttp://twitter.com/justincc>
_______________________________________________
Opensim-dev mailing list
Opensim-dev at opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
<blockedhttp://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
<blockedhttp://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
<blockedhttp://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
<blockedhttp://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/20150303/ab3c8a82/attachment.bin>
More information about the Opensim-dev
mailing list