|Anonymous | Login | Signup for a new account||2020-01-25 23:58 PST|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007709||opensim||[REGION] Physics Engines||public||2015-08-29 07:17||2015-09-05 04:41|
|Target Version||Fixed in Version|
|Summary||0007709: Simulator Framerate Reporting - Refers to closed bug (unable to reopen) (0029003)|
|Steps To Reproduce||N/A|
|Additional Information||In my previous report, Bluewall closed the issue with response:|
'New metrics reflect the actual frame rates and what you see now is correct. In the past, these numbers were elevated to roughly match what you would see in SL.'
This is fine, but from a viewer development perspective - other than adjusting the server framerate warnings, which causes all sorts of compatibility problems for end users - I would like to know if this is simply a matter of the multipliers having been adjusted to reflect these metrics, or if the metrics update was made in accordance with some other fix. In other words, if I were to recompile opensim and restore the previous multipliers, would this break anything ?
If the justification for this is simply a re-think on what opensim would like to see reflected in these metrics, would it not be better to revert to the previous state in order to minimise client compatibility issues.
A little understanding of the work undertaken here would be very much appreciated.
|Tags||No tags attached.|
|Git Revision or version number|
|Run Mode||Grid (1 Region per Sim)|
|Environment||Mono / Linux32|
|Viewer||singularity and firestorm|
|Attached Files|| Firestorm-4-7-3-Lag-Meter-is-Present-Contrary-to-Help-Info.jpg [^] (299,813 bytes) 2015-09-02 01:49|
lagopen.png [^] (12,092 bytes) 2015-09-05 04:39
lagclosed.png [^] (10,047 bytes) 2015-09-05 04:40
The changes to metrics came to us from the MOSES project, who, in order to be able to obtain accurate measurements, have removed the formerly used "fudge factor".
The ensuing discussion revealed that even scientific papers had been written that referred to the inflated measurements as if they were actual measurements because the fact that the values were fudged was never really known.
We are seeing a wider adoption of the needs of OpenSim in the viewer developer teams, so I would say that, in the interest of retaining true measurements, the viewers should adjust their warning thresholds, etc., rather than OpenSim going back to a faked measurement.
Comments are welcome and if this leads to a wider discussion it should be taken to the development mailing list.
Issue is, we're not gonna know what thresholds to use, because there will be different legacies of OpenSim deployments and forked codebases with each their own threshold, and even on the same version, a deployer can potentially change the framerate in their OpenSim.ini, it goes from there as MinFrameTime. Currently, it's at 0.089 seconds, which gives a perfect framerate of 11.2-ish. However, a deployment which uses a multiplier will be effectively choked to death if it were to deliver this "good" value.
I think you should give the viewer the value of MinFrameTime or its reverse as max framerate, whatever, as a region cap.
alecia ashbourne (reporter)
Thank you for that Melanie, I haven't had time to study the code in any detail here yet, so I can't really comment further, perhaps Siana is better understanding of this than me. However I would just like to add, that this was not brought to my attention, but rather raised as an issue on my regions by my friends 'it's awfully laggy here', so I put out a temporary 'pan' fix for a few popular viewers until some client updates are released.
I expect ultimately if we head this way, and perhaps other OpenSim mods, then it will lead to a forking of the clients. Perhaps this is OK, I haven't really given that much thought :) Either way, poorly researched scientific papers are of less importance than end user experience I think, and it's good to keep client developers in the loop when it's something that directly affects the interface. This sort of thing should be put out rather than found out. I'm sure there will be a record of the procedure somewhere, but no one seemed to be aware that the metrics had changed.
Thank you again for the clarification, it's very much appreciated.
|People should not say "it's laggy" from looking at stats, but only if they _experience_ lag. Which, I would assume, they didn't, they probably just looked at some inherently inaccurate "Lag meter".|
alecia ashbourne (reporter)
edited on: 2015-09-01 18:14
Yes Melanie, I quite agree, but this is end users experience I'm referring to, I can't dictate how they should express themselves. I apologise if my comments came across as pedantic, I was just trying to be objective.
The 'inherently inaccurate lag meter' as you put it, was the very reason I opened this mantis, so perhaps the advice to Client developers should be that the lag meter should now be considered redundant - after all, it is now redundant. Then no solution is necessary.
edited on: 2015-09-02 02:26
Checking things out that are noted here... I see that the Lag Meter in Firestorm has a red indicator whenever the "Server" framerate is below 20. Whereas with the latest dev master r/26205 my Sim FPS and Physics FPS seems to be solid and unchanging at 10.6666667 on our grids.
I have reported a mistaken comment about a lag meter not being in the latest versions of Firestorm anyway. Is there something we could note to the Firestorm (and other third party) viewers as to what OpenSim specific settings are "normal" there? is it as simple as asking for the viewer lag meter "green" server status SL figure to be 20 and the OpenSim one 10?
See attached screenshot
alecia ashbourne (reporter)
For now, just to inform them of this change, would be good I think.
What the Client developers choose to do with it will be up to them I expect. I chose a different approach - see pics attached.
However it occurred to me that perhaps 'time dilation' would be better for this indicator ? This way at least there would be no compatibility problem between SL and Opensim for server health.
|2015-08-29 07:17||alecia ashbourne||New Issue|
|2015-08-29 09:29||aiaustin||Summary||Reffers to closed bug (unable to reopen) (0029003) => Refers to closed bug (unable to reopen) (0029003)|
|2015-08-29 13:18||melanie||Note Added: 0029390|
|2015-08-29 16:18||siana||Note Added: 0029391|
|2015-09-01 07:20||alecia ashbourne||Note Added: 0029406|
|2015-09-01 11:11||melanie||Note Added: 0029409|
|2015-09-01 15:24||alecia ashbourne||Note Added: 0029410|
|2015-09-01 18:14||alecia ashbourne||Note Edited: 0029410||View Revisions|
|2015-09-02 01:48||aiaustin||Note Added: 0029411|
|2015-09-02 01:48||aiaustin||File Added: Firestorm-4-7-3-Lag-Meter-is-Present-Contrary-to-Help-Info.jpg|
|2015-09-02 01:49||aiaustin||File Deleted: Firestorm-4-7-3-Lag-Meter-is-Present-Contrary-to-Help-Info.jpg|
|2015-09-02 01:49||aiaustin||File Added: Firestorm-4-7-3-Lag-Meter-is-Present-Contrary-to-Help-Info.jpg|
|2015-09-02 01:50||aiaustin||Summary||Refers to closed bug (unable to reopen) (0029003) => Simulator Framerate Reporting - Refers to closed bug (unable to reopen) (0029003)|
|2015-09-02 01:52||aiaustin||Note Edited: 0029411||View Revisions|
|2015-09-02 02:01||aiaustin||Note Edited: 0029411||View Revisions|
|2015-09-02 02:26||aiaustin||Note Edited: 0029411||View Revisions|
|2015-09-05 04:39||alecia ashbourne||File Added: lagopen.png|
|2015-09-05 04:40||alecia ashbourne||File Added: lagclosed.png|
|2015-09-05 04:41||alecia ashbourne||Note Added: 0029415|
|Copyright © 2000 - 2012 MantisBT Group|