[Opensim-dev] Open Simulator Metrics Reporting Changes (UNCLASSIFIED)

Tommy Anderberg Tommy.Anderberg at simplicial.net
Sat Apr 18 20:02:13 UTC 2015


On Fri, 17 Apr 2015, Douglas Maxwell wrote:
> The time it took for the physics and simulation to run not including
> the sleep time, divided by the minFrameTime passed into the program from
> the OpenSimDefaults.ini file variable MinFrameTime. This would mean that a
> value of 1 is no sleep necessary, less than 1 and the program slept for some
> remaining amount of time, and greater than 1 the physics and simulation
> took longer to run than the allotted time.

On Sat, 18 Apr 2015, Sean M wrote:
> Our proposed changes positively unbinds dilation; the new
> calculation ranges from [0:Infinity). The previously intended range of
> [0:1] artificially places a limit on how long the simulator has waited for
> physics; this limit is not accurate because, theoretically, a physics frame
> can take forever.

As far as I can see, Dahlia et al. are pointing out that you are using 
the inverse of the original (SL) definition of time dilation. A time 
dilation of 0.0, according to SL, means that the simulator has come to a 
stand-still, so a single frame is taking forever to process.

There is therefore no "artificial limit" on the sim sloth reportable 
with a range [0,1].

You could argue that there is an artificial limit at the other end of 
the range: if an SL sim reports time dilation 1, that only says "I'm 
fine", but not how much spare capacity there is.

Couldn't you just report 1.0/(what you proposed)? Then you would have 
compatibility with the SL definition, plus new information about extra 
capacity in the 1+ range (easily capped to 1 in viewer code if need be).



More information about the Opensim-dev mailing list