RE: "Where does this number come from?"
The rate of simulation updates is always an arbitrary number that
depends on what kind of simulation you have and what kinds of user
experiences you want to support. A batch-style simulation with no
interactivity should run as fast as it can -- so, no sleeping in between
the iterations. An interactive simulation, however, needs to preserve
the sense of time for the observers. Hence the game loop being on a
constant time window, so that the simulation proceeds at a predictable
rate for the observers. How fast the rate is depends on the user
experience we want to support; faster is not always better.
In that example tutorial that I pointed to the simulation loops at 22
fps. OpenSim loops at 11 fps. Increasing the rate would increase the
network traffic without much benefit in terms of user experience: many
properties being passed to the clients already account for things like
velocity and direction that the clients can smooth over long periods of
time. Ideally, the update loop would be very small (say, 1/sec), so that
the number of messages to clients would be much lower. We would need to
figure out how to encode "smoothable" information over that much time...
and that's a hard research problem.
On 3/2/2015 3:42 PM, Justin Clark-Casey 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
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
