[Opensim-dev] [Non-DoD Source] Re: Still on Sim and Phys Frames per Second (FPS)
Teravus Ovares
teravus at gmail.com
Tue Nov 17 06:08:12 UTC 2015
While I understand your frustration here is more about who made the change
and who it's connected to which is a political thing... For me, it's not
at all a political problem and entirely a technical problem. Nobody knew
during the 3 months you mentioned..... the affect it would have on
existing viewers.
It certainly wasn't DISCLOSED BY YOU that that the change would make
viewers with a Lag meter show the sims as perpetually laggy.
I'm not saying that you did anything wrong... at that point... you
probably didn't know either... since, you said for yourself, for the most
part you're using your own WebGL stuff because the viewer licensing is very
complex.
Even though before, I didn't think you were doing anything wrong.... ,
now... I feel like you ARE doing something wrong in the way that you're
handling this.
What cost are you willing to accept to make a stat accurate and NOT make
some kind of compromise like I suggested... ,that Melanie had ALREADY
implemented by the time I suggested it? Are you willing to make
OpenSimulator less usable for many users so you can have certain bits in
the stream in a certain spot and are not happy with it being in a separate
spot to keep everything usable for a wide audience?
I understand that you 'were' trying to help. However, it seems to have
morphed into an attempt at manipulation through politics. I know you're
frustrated... I understand that it is HARD to work in groups and
coordinate teams. I have dealt with this MANY times during my
OpenSimulator contributions. It is super frustrating when I'm super
excited about a nifty new functionality that I contributed... only to
have someone in core say it breaks something important and have it forced
to be relegated to a configuration option... It is frustrating.. it
really is. However, when working with teams... GOOD communication and
coordination is REQUIRED. I cannot go on my own and expect everything to
be nice and simple when I hand over a slab of code that I worked on
separately. I also can't make tsunami waves until I make some normal sized
waves that people enjoy surfing. While communicating with someone...
the onus is on me, being the one doing the communicating, to be sure that
the other party understands and receives my message clearly. I can't
expect them to read my mind or react well to increasing frustration.
Frustration is an unfortunate part of the code contribution process. Have
you ever contributed code to Linux? Are you ready to have your coding
skills over analysed by hundreds of developers.. some of whom have
absolutely no manners?
Then, you made a public stink about reporting statistics. Which was cool
because we do want accurate stats... I said before that I wanted accurate
statistics (It has been repeated in these communications multiple times)...
however I WARNED to be careful with the stats because of the viewer
issues.
In the end, it DID cause problems with the viewer. Unfortunately, for us,
it is entirely impractical to expect all viewers to change... When the
viewer developers DO make concessions and change, we are EXTREMELY
grateful. Those viewer code bases are NOT easy to deal with. In the end,
the only thing that I have control over is myself.
So, technical solutions were proposed.... and here's where I think it
went wrong. Instead of compromising and working out a solution
constructively... there was all of this drama and finger pointing...
and instead of dealing with it constructively you struck out against the
fact that it was there and made accusations against people based on their
affiliations. Then, you doubled down on that.... all the while, a
simple fix to what now was a BUG was implemented to resolve the issue for
the immediate... and ACTUAL constructive solutions were being devised and
implemented for the long term.
>From a technical perspective, it is super simple to report the 'accurate
stats' in another place and make sure it's highly documented. SIMPLE
to do. It doesn't require all of this drama...
Much like you called out the code on the FPS issue, I'm calling you out on
the political drama now. It is entirely unnecessary and even harmful at
this point. Instead of focusing on a solution that will work for
everyone.. you're sticking on this one thing... over and over again.
How many times can you beat that dead horse? Thank you for letting us
know. The community is aware of that issue now. You have successfully
brought it to our attention and solutions are being devised and implemented
so proper testing can be done.. if not by you then other people.
"The bridges are burned.", OK. That's a stance of someone who doesn't
really care anymore. I'm fine with that. For me, it means, less
drama, more constructive solutions. Again, you successfully brought that
issue to our attention. Thank you for your contributions to OpenSimulator
and I wish you well in your future endeavors. May they be awesome and
innovative and wildly successful.
Lets move on to other technical issues.
Regards
Teravus
On Mon, Nov 16, 2015 at 8:56 PM, dz <dz at bitzend.net> wrote:
>
>
> On Mon, Nov 16, 2015 at 7:33 PM, Teravus Ovares <teravus at gmail.com> wrote:
>
>> Regarding this... why are we not co-opting a different, currently
>> unused, sim stats for the OpenSimulator 'Real performance' counter? There
>> are many unused simstats. If we keep the fudge factor on the main one,
>> the viewer lag meter are happy, and we put the real value in a different
>> sim-stat, the performance analysis can take place accurately.
>>
>>>
>>>
> Teravus..
>
> The whole point of starting this conversation was that WE HAD THESE
> CONVERSATIONS.. We had a community forum discussion on how to implement
> reporting of the correct statistics. The Moses group found a comment
> buried in the source code and asked about WHY someone decided to multiply
> the Physics frame rate ( which is LOCKED at 11 FPS ) by a factor of 5...
> No one on core could really explain it until Justin suggested reaching
> out to you.. That grew into a discussion of whether it made any sense to
> continue to report "politically correct" numbers or the actual Physics
> frame rate. The overwhelming majority of the people who responded
> indicted that it didn't make ANY sense to continue reporting the bad
> stats. The answers we got from the core team was that it might break
> performance monitoring scripts or have an effect on some internal
> calculations... There was an extended period of discussion to allow folks
> to make suggestions or comment on the things that would break It took
> almost 3 months from the beginning of the discussion to the time it was
> applied. There was NO guidance from core that it was in any way important
> to maintain the functionality of an obscure feature in some un-maintained
> viewer code.
>
> The objection I raised to begin this debacle was that it seemed like a
> member of core had just randomly decided that after 3 months of asking
> folks to jump through hoops, and then 6 months of having the sky NOT
> fall, it was ok to make a unilateral decision to revert the patch ( or
> override it with some new hidden config variable that would only
> continue the confusion about what the actual Physics FPS rate was).
>
> After all is said and done...It still seems to me like that is the
> situation... I have given up trying to get any real discussion about
> who it was that demanded that we revert the patch so their NON ACCURATE
> lag meter blinks green instead of red. We have heard form other grid
> owners, we have heard from viewer devs, we have heard from academics
> whose reputations may have been tarnished by publishing incorrect data.
> Bottom Line... One core member has decided that it is ok to ignore the
> efforts of this forums community and introduced a solution that lets the
> same code base report 55 OR 11 for the exact same statistic in the exact
> same code base, Its also been decided that it is STILL correct to add
> yet another level of complexity and possible source of confusion to the
> situation by renaming our Fudge factor/lie the NORMALIZED number.
>
> I can't code like members of core, I can't seem to influence the
> decisions they are determined to make with regards to this insanity..
> This is not a technically complicated issue... it is simply a matter of
> making a decision about what is correct. Apparently " correct " is
> related to the Euros that some unknown benefactor is willing to put up to
> make the lights blink green. WE ( nearly 95% of everyone who
> participated in the original period of discussion) had agreed that
> reporting the correct number was the right thing to do MOSES spent
> manpower and money to go through the process of getting a patch
> submitted/corrected, and applied, It WAS NOT a problem for anyone
> except for some unknown users on some unnamed grid ( who have YET to
> speak for themselves ). My objection remains... It is NOT proper to be
> able to bypass the community decision making nature WE assumed was the
> proper mechanism to resolve such issues. We have had close to 150
> posts on this topic in the past 2 weeks and NO ONE has been able to
> explain why it is the correct decision to revert the patch AND ignore the
> requests and almost unanimous agreement that the way things have been for
> 6 months was the best technical and political decision.
>
> I am committed to making OpenSim work.. I am sure there are folks who
> have seen this debacle unfold who are now less committed or interested in
> trying to participate
> with a technical group that believes it is politically "correct" to set
> such a precedent ( ignoring community forum input in favor of backroom
> "deals")... How can there possibly be a level of confidence in the
> platform/community if it takes 9 months to come to an agreement that a
> Physics Frame Rate that is LOCKED at 11FPS should not be reported at 11
> FPS??? Its not a complicated situation, It isn't a hard question...
> But it has turned into a real eye opener on the inside workings of this
> project for me (and from the comments I've received offline, for a large
> number of others).
>
> The lag meter didn't work before the numbers changed. At best it was a
> random guess that was likely at least 10% off. The original code would
> cast the floating point FPS number to an int before multiplying by some
> random factor of 5 to make sure that jitter didnt skew it wildly... It
> STILL doesn't work. Even the viewer devs who participated and went
> through the trouble to correct for the 11FPS number told us, the %
> levels at which the lights are green, yellow , or red are different
> for OpenSim and "that other grid". Melanies' solution means that now
> they have to rework their code to use her new magical mechanism to
> transmit the number 5 from Opensim to the viewer so it can do the
> multiplication...It also means that grid operators have to be able to
> explain why the same stat on different grids can be just as correct when
> it says 11 as when it says 55. That's not my problem, but I feel
> sorry for the honest grid operators who choose to tell the truth, and
> face charges that their grid is 5x slower than some other grid where
> the admin doesn't even know enough to change the new INI config value.
>
> Do I sound frustrated yet?
>
> Please don't ask that question NOW.. The bridges are burned.
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20151116/2e3ece2b/attachment-0001.html>
More information about the Opensim-dev
mailing list