[Opensim-dev] [Non-DoD Source] Re: Still on Sim and Phys Frames per Second (FPS) (UNCLASSIFIED)

Glenn Martin gamucf at gmail.com
Mon Nov 9 18:11:01 UTC 2015


It would seem to me that correctness should be driving principle and not the size of the group that may need to make some effort. 

Glenn

Note: Sent from my cell phone. The opinions and thoughts in this email are my own and do not reflect those of any other person or organization. 

> On Nov 9, 2015, at 1:08 PM, Melanie <melanie at t-data.com> wrote:
> 
> What we as core need to consider is that here the needs of the few
> people doing research cannot outweigh the needs of the many who want
> the viewer to function as expected. Therefore the minority who want
> to do research should be the ones who change a setting, not the
> majority interested in a working lag meter.
> 
> I have made several suggestions how it may be possinle to transit
> gracefully and without breaking things; alas, they were all ignored
> in favor of principle thumping.
> 
> - Melanie
> 
>> On 09/11/2015 19:00, Terry Ford wrote:
>> I think for sake of accuracy we should leave it by default to report 
>> correctly.
>> For those who do not want the accurate results and prefer to use the 
>> multiplied values, give them an option in the ini file to set 
>> StatsFudgeFactorOn = true or something similar.
>> Doing this would satisfy both sides without any further discussion and 
>> would then allow the grid/region operator the option to run it they way 
>> they prefer as it should be.
>> 
>> ~Terry
>> 
>>> On 11/9/2015 12:52 PM, Michael Emory Cerquoni wrote:
>>> 
>>> Personally i think we should have left the fudge factor stats alone 
>>> and introduced new non multiplied stats. Forcing everyone to change 
>>> because one single project has a goal is not great. If the projects 
>>> goal is to do back end analysis who cares what we send to the viewer.
>>> 
>>> On Nov 9, 2015 9:48 AM, "Melanie" <melanie at t-data.com 
>>> <mailto:melanie at t-data.com>> wrote:
>>> 
>>>    Viewers WILL have to change but something like the "Lag Meter" does
>>>    depend on some way of generating a normalized value.
>>> 
>>>    This can either be done by normalizing to a standard frame of
>>>    reference, most often 0.0 .. 1.0 is used for this, or normalizing to
>>>    a known value, e.g. 55 fps.
>>> 
>>>    In the absence of a normalized value, viewers would not be able to
>>>    calculate the lag meter unless the stats packet also contains a
>>>    value telling the viewer what "normal" is. This is currently not the
>>>    case.
>>> 
>>>    With sim stats being a UDP packet, we really can't add fields easily
>>>    without breaking with the SL standard and all viewers strive to not
>>>    only work in OpenSim but also in SL.
>>> 
>>>    One could possibly add the "normal" value to the SimulatorFeatures
>>>    cap, since it is not expected that that value would or could change
>>>    while clients are logged in. That still would require viewers to
>>>    change and viewers are slow to change.
>>> 
>>>    Sadly, things required only by OpenSim are incorporated much less
>>>    speedily than things required for continued SL compatibility. We
>>>    should therefore strive to provide what is needed for the viewers to
>>>    adapt but some of us are not in a position to leave the current
>>>    users out in the rain.
>>> 
>>>    - Melanie
>>> 
>>>>    On 09/11/2015 18:40, Terry Ford wrote:
>>>> DigiWorldz and Great Canadian Grid are running the newer code
>>>    with stats
>>>> reporting 11fps without issue.
>>>> When we first made the change, we let everyone know and we've
>>>    never yet
>>>> had any complaints about it.
>>>> I've not seen any issues regarding the change on my end so far.
>>>> 
>>>> I personally prefer the corrected stats and I think as long as
>>>    everyone
>>>> is made aware of the changes and the reasons, I don't think
>>>    there would
>>>> be any issues.
>>>> 
>>>> I am a fan of the Architect Frank Lloyd Wright and I remember
>>>    reading a
>>>> story about him once...
>>>> Someone had complained to him that his design on one of his
>>>    builds was
>>>> very poor and it was leaking water each time it rained... his
>>>    reply...
>>>> grab a bucket and catch the water.
>>>> While his build looked awesome, it had an obvious flaw, but
>>>    instead of
>>>> addressing it, he indicated using a bucket to catch the water
>>>    would fix
>>>> the issue.
>>>> Isn't that what we are essentially doing here... grabbing buckets?
>>>> I personally prefer a roof which doesn't leak.
>>>> 
>>>> ~Terry
>>>> 
>>>> 
>>>> 
>>>>> On 11/9/2015 12:31 PM, Zadark Portal wrote:
>>>>> +1 dz
>>>>> 
>>>>> I cannot add to the well informed technical reasonings already
>>>>> contributed.
>>>>> 
>>>>> But, the suggested amendment is purely cosmetic. I fail to
>>>    understand
>>>>> why grid operators are persistently unable to portray the
>>>    importance
>>>>> of accurate measurements to their clients.
>>>>> 
>>>>> Of equal concern is perpetuating a culture where non evidence based
>>>>> observations prevail within the user community only to be
>>>    dismissed by
>>>>> equally subjective reasoning.
>>>>> 
>>>>> +1 dz (again)
>>>>> 
>>>>> Z
>>>>> 
>>>>> On 9 November 2015 at 16:37, Maxwell, Douglas CIV USARMY RDECOM ARL
>>>>> (US) <douglas.maxwell3.civ at mail.mil
>>>    <mailto:douglas.maxwell3.civ at mail.mil>
>>>>> <mailto:douglas.maxwell3.civ at mail.mil
>>>    <mailto:douglas.maxwell3.civ at mail.mil>>> wrote:
>>>>> 
>>>>>    Classification: UNCLASSIFIED
>>>>>    Caveats: NONE
>>>>> 
>>>>>    +1 dz
>>>>> 
>>>>>    I'm not trying to start a flame war, so pls take these
>>>    comments as
>>>>>    my own
>>>>>    opinion.
>>>>> 
>>>>>    To be honest, I don't understand how the counter-argument
>>>    to accurate
>>>>>    reporting could possibly be taken seriously.  We have done some
>>>>>    intense
>>>>>    troubleshooting on the OpenSimulator to try to find where
>>>>>    instabilities and
>>>>>    performance enhancements can make most sense. Pandering to the
>>>>>    users by
>>>>>    artificially inflating the numbers does no one any good and is
>>>>>    quite frankly,
>>>>>    weak sauce.  I'm sorry the lag meters don't work anymore,
>>>    but that
>>>>>    is the
>>>>>    consequence of improperly reporting the stats in the first
>>>    place.
>>>>>    The correct
>>>>>    fix here isn't to re-break stats reporting.
>>>>> 
>>>>>    Secondly, I don't understand how the Devs plan(!) to
>>>    address the
>>>>>    three major
>>>>>    components of the CORE that need work to improve stability and
>>>>>    scalability.
>>>>>    We (MOSES) are testing the new PhysX addition and could not
>>>    do our
>>>>>    jobs
>>>>>    without proper stats reporting. In fact, months of work (and
>>>>>    money) was wasted
>>>>>    last year when we attempted to address physics issues and
>>>>>    profiling only to
>>>>>    find out we couldn't trust the data we were collecting!
>>>>> 
>>>>>    Our next work will involve addressing the client manager issues
>>>>>    and will
>>>>>    hopefully yield a workable architecture to allow dozens of
>>>    people
>>>>>    to log in
>>>>>    simultaneously without lag or impact on the rest of the
>>>>>    simulator.  Again,
>>>>>    can't do this without proper stats reporting.
>>>>> 
>>>>>    Think of this as a MacOSX moment.  Might break some old things,
>>>>>    but in the end
>>>>>    you will be better for it.
>>>>> 
>>>>>    v/r -doug
>>>>> 
>>>>>    Douglas Maxwell, Ph.D.
>>>>>    Science and Technology Manager
>>>>>    Virtual World Strategic Applications
>>>>>    U.S. Army Research Lab
>>>>>    Simulation & Training Technology Center (STTC)
>>>>>    (c) (407) 242-0209 <tel:%28407%29%20242-0209>
>>>>> 
>>>>> 
>>>>> 
>>>>>    -----Original Message-----
>>>>>    From: opensim-dev-bounces at opensimulator.org
>>>    <mailto:opensim-dev-bounces at opensimulator.org>
>>>>>    <mailto:opensim-dev-bounces at opensimulator.org
>>>    <mailto:opensim-dev-bounces at opensimulator.org>>
>>>>>    [mailto:opensim-dev-bounces at opensimulator.org
>>>    <mailto:opensim-dev-bounces at opensimulator.org>
>>>>>    <mailto:opensim-dev-bounces at opensimulator.org
>>>    <mailto:opensim-dev-bounces at opensimulator.org>>] On Behalf Of dz
>>>>>    Sent: Saturday, November 07, 2015 8:54 PM
>>>>>    To: opensim-dev at opensimulator.org
>>>    <mailto:opensim-dev at opensimulator.org>
>>>>>    <mailto:opensim-dev at opensimulator.org
>>>    <mailto:opensim-dev at opensimulator.org>>
>>>>>    Subject: [Non-DoD Source] Re: [Opensim-dev] Still on Sim
>>>    and Phys
>>>>>    Frames per
>>>>>    Second (FPS)
>>>>> 
>>>>>    All active links contained in this email were disabled. Please
>>>>>    verify the
>>>>>    identity of the sender, and confirm the authenticity of all
>>>    links
>>>>>    contained
>>>>>    within the message prior to copying and pasting the address
>>>    to a
>>>>>    Web browser.
>>>>> 
>>>>> 
>>>>>    ________________________________
>>>>> 
>>>>> 
>>>>> 
>>>>>    The issue is promoting accurate reporting of basic performance
>>>>>    measurement
>>>>>    statistics.  ( something that has  not  achieved nearly enough
>>>>>    serious
>>>>>    attention )
>>>>> 
>>>>>    Significant money and manpower is currently being directed at
>>>>>    efforts to
>>>>>    improve simulator performance.
>>>>>    It is a simple fact that the continued funding of these efforts
>>>>>    relies on
>>>>>    documenting the ACTUAL improvement  against the ACTUAL original
>>>>>    performance
>>>>>    characteristics.
>>>>>    It is impossible to justify these efforts  when the reported
>>>>>    numbers  are
>>>>>    "made up"  and  THAT fact is not documented except in some
>>>    obscure
>>>>>    comment
>>>>>    left behind in the source code.
>>>>> 
>>>>> 
>>>>>    It is unfortunate that the original decision to include a
>>>    "Fudge
>>>>>    factor
>>>>>    multiplier" has created a pool of  mis-informed users (
>>>    including
>>>>>    myself and
>>>>>    the  viewer developers   ) .
>>>>>    This mistake was complicated  by the fact that until very
>>>    recently
>>>>>    there was a
>>>>>    philosophical divide that prevented  OpenSim and viewer
>>>    developers
>>>>>    from
>>>>>    cooperating on issues like these.
>>>>>    This decision to "play pretend" with performance stats
>>>    effectively
>>>>>    damaged the
>>>>>    reporting credibility of everyone  who published these
>>>>>    inaccurate  results,
>>>>>    It also created  a rift between the OpenSim and viewer
>>>    developers
>>>>>    over the
>>>>>    decision to NOT discuss  the impact  of implementing the
>>>    change.
>>>>>     The fact
>>>>>    is,  there are  numerous places in the OpenSim framework where
>>>>>    numbers  are
>>>>>    "made up"  just so that  a number appears in performance
>>>    reports.
>>>>>    That an
>>>>>    effort is being made to correct those  sources of
>>>    mis-information
>>>>>    should be
>>>>>    welcomed.
>>>>> 
>>>>> 
>>>>>    It seems to me that the decisions  made by core should be
>>>    made in
>>>>>    favor of
>>>>>    supporting the ongoing efforts  to accurately document and
>>>    improve
>>>>>    simulator
>>>>>    performance.
>>>>>    Justin realized this and lead many of the efforts  to add some
>>>>>    measurement
>>>>>    metrics.    Even  with those efforts, we still cannot
>>>    measure  basic
>>>>>    statistics like Events per Second sent to the script engine, or
>>>>>    tie those
>>>>>    events to whatever script is handling them.  This makes
>>>>>    identifying the
>>>>>    scripts  ACTUALLY responsible for "lagging" a region impossible
>>>>>    using the
>>>>>    traditional  TOP SCRIPTS report in region manager window.
>>>>> 
>>>>>    I would  agree that a simple solution might be to allow grid
>>>>>    managers  to add
>>>>>    back the Fudge Factor to appease their  vocal users, but would
>>>>>    disagree that
>>>>>    the PROPER decision  should be to continue to report inaccurate
>>>>>    results.  It
>>>>>    would be  just as easy  to implement a multiplier in the viewer
>>>>>    code "Lag
>>>>>    Meter",  This  would also allow the accurate reporting of
>>>>>    statistics in the
>>>>>    Advanced Statistics window  and  administrative reporting. I
>>>>>    believe it was
>>>>>    also one of the suggested resolutions put forth by the viewer
>>>>>    developers... It
>>>>>    should be clear to anyone who has spent time in world  that the
>>>>>    "lag meter" is
>>>>>    incorrect...  You can walk, build, chat  and TP with the same
>>>>>    level of sim
>>>>>    performance as you could  before the  numbers were changed.
>>>    We've
>>>>>    overlooked
>>>>>    the fact that viewers have behaved  differently in OpenSim and
>>>>>    "that other
>>>>>    grid"  for years.   Why is it  "all of a sudden" CRITICAL that
>>>>>    this one
>>>>>    viewer feature  HAS to be the same?   In these days  when core
>>>>>    developers
>>>>>    are releasing  viewers, I cannot understand the urgency of
>>>>>    accommodating a
>>>>>    minor feature of  one viewer whose developers have already
>>>>>    demonstrated a
>>>>>    willingness to work with OpenSim to tailor a configuration
>>>    to meet
>>>>>    our needs.
>>>>> 
>>>>> 
>>>>> 
>>>>>    On Sat, Nov 7, 2015 at 1:19 PM, Melanie <melanie at t-data.com
>>>    <mailto:melanie at t-data.com>
>>>>>    <mailto:melanie at t-data.com <mailto:melanie at t-data.com>> <
>>>>>    Caution-mailto:melanie at t-data.com
>>>    <mailto:melanie at t-data.com> <mailto:melanie at t-data.com
>>>    <mailto:melanie at t-data.com>> > >
>>>>>    wrote:
>>>>> 
>>>>> 
>>>>>            The issue here is the so-called "lag meter". Since
>>>    removal
>>>>>    of the
>>>>>            multiplier, this reports all opensim regions as
>>>    laggy, without
>>>>>            exception. Users' trust in the "lag meter" is
>>>    damaging OpenSim
>>>>>            reputation. This is not a value that is merely for
>>>>>    display; the
>>>>>            viewer uses this value for computations that are
>>>    then used to
>>>>>            "judge" a sim to be "laggy" if it's below 35 or so fps.
>>>>>    OpenSim now
>>>>>            always reports a lesser value. This is damaging and
>>>    needs
>>>>>    to be made
>>>>>            configurable and by default match the viewer's
>>>    expectations.
>>>>> 
>>>>>            - Melanie
>>>>> 
>>>>> 
>>>>>>            On 07/11/2015 16:38, Seth Nygard wrote:
>>>>>> While I understand the arguments surrounding the
>>>>>    original decision to
>>>>>> report values closely matching "the other grid", IMHO
>>>>>    doing so created
>>>>>> an incorrect understanding in many users' minds
>>>    of how
>>>>>    things work
>>>>>> and/or behave.  We are not that other grid and should
>>>>>    never pretend to
>>>>>> be.  Had figures been reported correctly in the
>>>>>    beginning then there
>>>>>> would be no confusion now surrounding this subject.
>>>>>    However avoiding
>>>>>> confusion is a poor reason to roll back and once
>>>    again
>>>>>    report the
>>>>>> artificially inflated values.   It is better to
>>>    simply
>>>>>    educate and make
>>>>>> it clear that the value of 11fps is indeed the
>>>    correct
>>>>>    value to expect,
>>>>>> and is in fact the true value things always have
>>>    ran at
>>>>>    despite what any
>>>>>> inflated reported value said.
>>>>>> 
>>>>>> It is true that many scripts and tools have
>>>    already been
>>>>>    written to use
>>>>>> the inflated values but they can all be changed with
>>>>>    relative ease.  The
>>>>>> viewers already have many aspects that are
>>>    different for
>>>>>    Open Simulator
>>>>>> so they can be changed easily as well for new
>>>    versions
>>>>>    also with
>>>>>> relative ease.  All we need to do as a community is
>>>>>    establish what the
>>>>>> correct and expected values are and then document and
>>>>>    communicate them.
>>>>>> 
>>>>>> As a user, scripter, tool developer, and grid
>>>    manager, I
>>>>>    for one want to
>>>>>> see true and accurate values for any and all metrics
>>>>>    regardless of where
>>>>>> they are shown or how they may be used.  I
>>>    therefore am
>>>>>    firmly against
>>>>>> rolling back to any older artificially inflated
>>>    values.
>>>>>> 
>>>>>> Regards
>>>>>> -Seth
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Opensim-dev mailing list
>>>>>> Opensim-dev at opensimulator.org
>>>    <mailto:Opensim-dev at opensimulator.org>
>>>>>    <mailto:Opensim-dev at opensimulator.org
>>>    <mailto:Opensim-dev at opensimulator.org>> <
>>>>>    Caution-mailto:Opensim-dev at opensimulator.org
>>>    <mailto:Opensim-dev at opensimulator.org>
>>>>>    <mailto:Opensim-dev at opensimulator.org
>>>    <mailto:Opensim-dev at opensimulator.org>> >
>>>     Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>>>    <
>>>     Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>>> 
>>>>> _______________________________________________
>>>>>            Opensim-dev mailing list
>>>>> Opensim-dev at opensimulator.org
>>>    <mailto:Opensim-dev at opensimulator.org>
>>>>>    <mailto:Opensim-dev at opensimulator.org
>>>    <mailto:Opensim-dev at opensimulator.org>> <
>>>>>    Caution-mailto:Opensim-dev at opensimulator.org
>>>    <mailto:Opensim-dev at opensimulator.org>
>>>>>    <mailto:Opensim-dev at opensimulator.org
>>>    <mailto:Opensim-dev at opensimulator.org>>
>>>     Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>>>    <
>>>     Caution-http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>    Classification: UNCLASSIFIED
>>>>>    Caveats: NONE
>>>>> 
>>>>> 
>>>>> 
>>>>>    _______________________________________________
>>>>>    Opensim-dev mailing list
>>>>> Opensim-dev at opensimulator.org
>>>    <mailto:Opensim-dev at opensimulator.org>
>>>    <mailto:Opensim-dev at opensimulator.org
>>>    <mailto:Opensim-dev at opensimulator.org>>
>>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Opensim-dev mailing list
>>>>> Opensim-dev at opensimulator.org
>>>    <mailto:Opensim-dev at opensimulator.org>
>>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Opensim-dev mailing list
>>>> Opensim-dev at opensimulator.org <mailto:Opensim-dev at opensimulator.org>
>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>    _______________________________________________
>>>    Opensim-dev mailing list
>>>    Opensim-dev at opensimulator.org <mailto:Opensim-dev at opensimulator.org>
>>>    http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at opensimulator.org
>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at opensimulator.org
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev


More information about the Opensim-dev mailing list