Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007709opensim[REGION] Physics Enginespublic2015-08-29 07:172015-09-05 04:41
Reporteralecia ashbourne 
Assigned To 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0007709: Simulator Framerate Reporting - Refers to closed bug (unable to reopen) (0029003)
DescriptionNew metrics
Steps To ReproduceN/A
Additional InformationIn 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.
TagsNo tags attached.
Git Revision or version number
Run Mode Grid (1 Region per Sim)
Physics EngineBulletSim
Script Engine
EnvironmentMono / Linux32
Mono Version3.2
Viewersingularity and firestorm
Attached Filesjpg file icon Firestorm-4-7-3-Lag-Meter-is-Present-Contrary-to-Help-Info.jpg [^] (299,813 bytes) 2015-09-02 01:49
png file icon lagopen.png [^] (12,092 bytes) 2015-09-05 04:39

png file icon lagclosed.png [^] (10,047 bytes) 2015-09-05 04:40

- Relationships

-  Notes
melanie (administrator)
2015-08-29 13:18

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.
siana (reporter)
2015-08-29 16:18

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)
2015-09-01 07:20

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.
melanie (administrator)
2015-09-01 11:11

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)
2015-09-01 15:24
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.

aiaustin (developer)
2015-09-02 01:48
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)
2015-09-05 04:41

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.

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker