[Opensim-dev] [Non-DoD Source] Re: Still on Sim and Phys Frames per Second (FPS)
Shy Robbiani
shy.robbiani at gmail.com
Tue Nov 17 15:52:59 UTC 2015
I'm very happy with the solution as it is now. It's the result of a
democratical process. Respectful discussion is necessary to find a solution
that works for all, keep that in mind before blaming each other and
starting a drama next time.
On Tue, Nov 17, 2015 at 7:08 AM, Teravus Ovares <teravus at gmail.com> wrote:
> 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
>>
>>
>
> _______________________________________________
> 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/20151117/6c78cd6d/attachment-0001.html>
More information about the Opensim-dev
mailing list