There is no bottleneck, it is the target value. The simulation is designed to run at this rate.
On Mon, Mar 2, 2015 at 1:00 PM, Mike Chase < [email protected]> wrote: > 11 does seem really low. I suppose someone has profiled this in the > past. Any idea what the bottleneck is. > > Mike > > > On 3/2/15 3:54 PM, Dahlia Trimble wrote: > > I believe 11 sim FPS is the target value. It would probably never go > above this, but a number consistently lower than 11 fps would indicate > performance problems. If the "lie" is simply a linear scaling, then it > would have no impact in the ability to use the number as a comparitive > statistic. since all such numbers would be similarly scaled. > > I also believe some of these numbers eventually make it to the viewers > and are used to adjust moving entity velocity when the sim is running > slowly. I'm not sure of the exact path but I think "time dilation" is > involved. Altering these values may induced undesirable movement effects > when the simulator is running slower than normal. > > Raising the target above 11 would also likely induce issues as other > parts of the code assume 11 is the target. > > On Mon, Mar 2, 2015 at 11:16 AM, Sean M <[email protected]> wrote: > >> There are 3 frame rates: *simulation*, *physics*, and *client*. Please, >> someone correct me if I am wrong: the *simulation fps* is how many >> simulation loops can be processed in a second, where each loop processes >> physics, scripting, region updates, etc; *physics* *fps* is just how >> many physics loops get processed per second, where each loop calculates >> collisions, gravity changes, and other movement updates for all appropriate >> objects in a region Both physics and simulation (phys/sim) fps are >> server-side. The fps the *client* is concerned with is graphics >> rendering on the viewer (firestorm, singularity, etc) and is literally how >> many visual frames/shots are displayed per second to the client. From a >> client point of view, 11fps is low because that is a low amount of image >> updates the client is visually seeing on their viewer. I am concerned with >> the simulation and physics FPSs being reported with highly inflated >> numbers. I want to use sim and phy FPSs as measures of how my region is >> performing but concerned that the correctionFactor of 5 is invalidly >> skewing these metrics, making both fps useless. >> >> Michael, or anyone else, do you know why OpeSim ticks at 11 fps? Why >> 11? Is my understanding of what constitutes a "frame" correct? >> >> On Mon, Mar 2, 2015 at 1:37 PM, R.Gunther <[email protected]> wrote: >> >>> 11fps ? is that not very low. 22fps gives more rome or 33fps. >>> But i admit that i read fps maby wrong, and have nothing today with the >>> framerate or smoothness on the screen.. >>> >>> >>> >>> On 2015-03-02 19:28, Michael Emory Cerquoni wrote: >>> >>> The reason physics and scripting are locked at 11fps is because this is >>> what the OpenSimulator heartbeat ticks at, the reason it is multiplied is >>> to satisfy the viewer statistics, I am not sure its possible to have it >>> report the legitimate numbers without some wierd side effects, but I could >>> be wrong, you would have to experiment, I suspect though that changing this >>> could lead to a lot of badness. >>> >>> On Mon, Mar 2, 2015 at 1:23 PM, Sean M <[email protected]> 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 >>>> >>>> >>> >>> >>> -- >>> Michael Emory Cerquoni >>> >>> >>> _______________________________________________ >>> Opensim-dev mailing >>> [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 >>> >>> >> >> _______________________________________________ >> Opensim-dev mailing list >> [email protected] >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> > > > _______________________________________________ > Opensim-dev mailing > [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 > >
_______________________________________________ Opensim-dev mailing list [email protected] http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
