I can confirm that since Havoc4 went mainstream, these performance dropouts continue to occur, although I'm not sure if they are happening as frequently.

My region, as reported, is a void/openspace too.

Lunata does seem to be stuck in this pattern, although it might be an unrelated problem that the Havok team might need to look at,

I have spoken to Sidewinder and they are now aware of this Jira, I am told they are looking into it.

Havok4 allows for pre-allocating memory specifically for the physics system. This doesn't actually limit the amount of memory physics may use (we do that separately), however there is a slight performance hit for allocating more memory (and releasing it later). We were a little over generous in our initial memory allocation AND were allocating the same amount for Open Space regions as normal regions. For the version currently on the beta grid we have dropped the initial allocation on regular regions from 128mb to 64mb, and void regions down to 16mb. It took me quite a bit of work (read: griefing my own sim) to bump past 64mb and even 16mb is more than enough for quite a bit

The problem with over allocating is that it starts to bump the processes into swap (where some memory is stored on disk) which is a huge performance hit.. This hit the void regions the most as they are sharing with 4x as many other regions.

There are tiny 1ms lag drops every 2 to 3 minutes, but this is normal for openspaces in my experience.

You are at 201314.0, 287661.4, 23.0 in Achilles Island located at sim2167.agni.lindenlab.com (216.82.16.172:13017)
Second Life Server 1.20.1.85162

[8:07] MystiTool HUD: Achilles Island Stats Warning: Time Dilation = 0.26 (<0.40), Sim FPS = 11 (<20)
[8:10] MystiTool HUD: Achilles Island Stats Warning: Time Dilation = 0.21 (<0.40), Sim FPS = 9 (<20)
[8:11] MystiTool HUD: Achilles Island Stats Warning: Time Dilation = 0.33 (<0.40), Sim FPS = 17 (<20)
[8:12] MystiTool HUD: Achilles Island Stats Warning: Time Dilation = 0.19 (<0.40), Sim FPS = 9 (<20)
[8:13] MystiTool HUD: Achilles Island Stats Warning: Time Dilation = 0.21 (<0.40), Sim FPS = 9 (<20)
[8:14] MystiTool HUD: Achilles Island Stats Warning: Time Dilation = 0.27 (<0.40), Sim FPS = 11 (<20)

The stats window shows this also..just that MystiTool is easier to cut and paste. Note that this is not even set to go off until fps drops under 20...and even then it is only checking once in a while, so it's not catching all the time that the sim is out of whack.

Also, the main parcel is now showing over 485 selected / sat upon, while none actually are. I find this interesting, as it is more than were showing like that before the update and sim restart!!! To be honest, I was sort of expecting that update to clear the selected / sat upon and at least reset it back to 0, even if that one wasn't fixed yet.

Never mind. Just because they are in a line does not mean the 4 are on the same processor. All I needed to do was look at the server name to see they were different. Just clutching at straws I guess, unable to believe that at least my sims problem was not solved in the update. My first "NOT FIXED" comment is still valid.

There was a big bug in the memory allocation that more than doubled the memory usage of open space regions and caused almost all cases of this. I did hedge on my previous comments that because this jira item describes a vague symptom that could be the symptom of many, many issues it may not 100% fix everyone. However! It fixed the majority of the issues, the memory usage on void regions is back within the realm of normal.

I can not, and will not, maintain a single bug for every bug that has a symptom of cyclical lag. Sorry. This bug is now specifically for the memory issue and is fixed.

Please feel free to create a new bug if you have the updated version and are still experiencing cyclical lag issues so that issue can be investigated separately. If you really want do please feel free to link it or add it in a comment so others who come here can find the new issue.

I am going to change the title of this bug to "Havok allocates too much memory and causes severe cyclical lag, especially for open space regions"

Also, all regions on the same host will be upgraded at the same time, which means that the memory bloat won't effect updated regions. If you are still seeing severe cyclical lag the problem is somewhere else.

There are some other performance issue jira's, for example SVC-2172

Thanks.

First you fold my original ticket SVC-2012 into this, then tell me that I am posting in the wrong place? You people are effing insane. I've been talking up with all my friends about what a great job you have been doing trying to roll out the fix for our problems. You may have fixed something..but not what I've reported, and you were the ones who decided it was the same issue, not me. So I'm the one that must be crazy, to continue to even deal with you blanking blanking blanks. Don't tell me everything is better, you've fixed the problem. It isn't, and you haven't, and your condescending blather to the contrary does not make it so!!!

The original bug should probably be unlinked and re-opened in this case, with comments specifically to the effect that the issue still exists in the latest simulator version.

Perhaps this is a point of contention but jira is not a tool for user benefit. It is a tool for developer benefit - so we can classify, document and track bugs through to resolution. Having a single bug for a vague symptom is easy for users (hey, the bug you want is already here) but impossible for devs and QA who need a way to track specific issues and specific fixes.

I don't mean to be insulting or condescending. What I am trying to do is make sure that your issue does get addressed - which it will not if it stays connected to this one.

This bug is fixed, I am sorry that it isn't your bug.

Aside from all the reasoning above - everyone involved here is human and mistakes are possible, and judgment calls are always being made. As I said before it was a judgment call to link your issue to this one because the symptoms matched. Now that we know they aren't the same issue we can move forward.

"Perhaps this is a point of contention but jira is not a tool for user benefit."

Well..since the JIRA is not a tool for user benefit, might I suggest to all the users following this little match that they, like me, no longer bother to use it.

If they are going to admit that what we think is important is of no relevance to them I see no reason to help them improve their product, and they can sit on their hands watching people flow away as soon as a product that actually competes in their niche arrives in the marketplace.

Develop that.

Again, I am sorry that the fix we thought would fix your issue turns out to not fix your issue. I have re-opened your original issue, changed the link to 'relates to' and assigned it to myself.

As far as jira is concerned I don't know any other way to help you.

That is not good for Jira, the developers or the other submitters.

It is a pity that your original bug got closed as duplicate, however, reopening that once it was clear they were two divergent issues would have been smarter. Certainly the tirade of abuse you launched was not warranted.