Re: Open Simulator Metrics Reporting Changes (UNCLASSIFIED)
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).