|
|
|
Raised the priority to critical as it severely impacts the use of openspace (void) regions. This is a major issue that should be adressed ASAP.
This issue is having a signficant impact on the SL sailing community since our sailing areas are over 90% open spaces sims. Our races and regattas are impacted.
Additionally the lifestyle of those that choose to live on open spaces land is being negatively impacted (this is NOT an issue of prims unless LL is going to tell us that the new prim limits recently provided is strictly cosmetic and has no basis in improved infrastructure). Since Dee Linden cannot be on all open space sims at all times.... perhaps a fix is in order. Seriously this IS an important issue.
I would like to point out that even with the latest Server version 1.21.0.85745 I am seeing the problem on several SIMs. I have gotten MANY complaints about this recently.
The frequency of the lag that I see is however greater then the originator of this issue stated. I see this happening nearly every minute. Time Dilation drops to as low as .21 and Physics FPS down to around 10. This occurs on several of my OPENSPACE SIMs even when I am the only one on it. No collisions occuring and scripts taking up less then 1.0 ms in total. BTW - any reason that this problem still is listed as UNASSIGNED? I've had numerous complaints from residents on my openspace sims also, seeing exactly the same issue. No collisions, total script load about 1 ms, and 1 or 2 avs on the sim.
As for the problem being UNASSIGNED, it appears its not only UNASSIGNED but UNLOOKED AT too. Unfortunately, that seems to be par for the course lately. This is one of two CRITICAL issues I'm watching. This one was logged 8 days ago, is up to 64 votes, and appears not to have even been looked at yet by a Linden. The other one (SVC-2129) was logged almost 3 weeks ago, on April 9th, involves significant content loss by many residents, and ALSO has yet to even be looked at by a Linden. Is this thing actually USED, or is it just supposed to make us feel better by posting or something?? Grrr, what does it take to get a CRITICAL problem looked at and worked on?!?!?! Note that since this issue was reported, someone (a Linden?) has noticed that it relates to svc-2005 (as noted above). If you read that jira entry you can see that this issue is being actively investigated, and is well-known by the Lindens.
I have not been following the various versions that are "live" in SL. Is the resolution discussed in svc-2005 still the beta grid version, or has it been deployed on the main grid? Is a fix on the way? Or is this something new (as indicated by the fact that this issue is still open, while the others have been closed). Also, I have the impression that this issue is not happening on ALL of my open space sims, but only some of them. Anyone else notice that? Poppet, the issue in
http://blog.secondlife.com/2008/04/17/rolling-restart-for-patched-120-server-deploy-april-17-19/ This current issue was opened two days after that, on the 21st. Although the basic symptom - openspace lag - is the same, the issues are different, and no there's no pending release that solves this problem. I'm not sure who linked I'm seeing this on all my openspaces, but all for me is only four of them, so my sample size is small. But the problem is clearly still here, with no known/announced fix on the way. Updated to indicate that the problem exists on the latest server release - 1.21.0
Well, keep in mind, I was benchmarking empty openspaces... to prove that it isn't merely load on the openspace causing it. If you have even a few physical objects bouncing around your openspace, it's going to be much worse. Linden Lab only officially supports very lightly loaded openspaces, which is why I proved it was happening on empty ones.
Note that my later monitoring did detect it happening about 10 times an hour... the initial times of occurance were with monitoring every 5 seconds, if you monitor every 1 second you do see some of the shorter bursts that last less than 5 seconds. Thank you everyone for the feedback. We are indeed aware of some severe performance issues and are working to track them down and address them. Unfortunately at this time we still don't know exactly what is causing these issues, but we do know that it effects all regions (not just open spaces), although it probably shows up in open spaces at lower load levels.
Viewers 1.20 or later have some extended stats in the ctrl-shift-1 window for physics details. I put these changes on a wiki page: https://wiki.secondlife.com/wiki/Simulator_Physics_Statistics If anyone is watching these stats when it is happening I'd be interested in some general idea of:
There are several performance jiras, I'm not sure this is the best catch all but it will do for now. I'll watch it to catch any replies. exactly what we are seeing on our openspaces. Reported it to support and of course it was behaving well. If LL advertises the prim limit on an openspace then it should be supported. Are there any guildelines on script loading for these. On the one reported there are only a few scripts with as Dallas reported above No collisions, total script load about 1 ms, and 1 avs on the sim.
Is there a "official and or results recognised" logging script that we can run over a time period on Open Sims that would help LL debug this ??
At this time we do not think we need more reports or more evidence. We have a good amount of test cases now that we are actively working on. If that changes we will let you know.
 I hope your close Kelly ... as 3 of our opens sims tonight are terrible close to worse than useless.. was building on one earlier .. rez a cube .. wait 20 to 30 seconds for it to appear... Load a Paskis Door script in a cube .. normally takes 10 to 20 seconds to load .. took over 3 mins
I hope it's close to being done also. I reported this in SVC-2012 on April 3...and linked it to
Cliff, you missed the point of Kelly's comments on 2005.
Just because a bug shares the same symptoms as a previous bug, does not mean it has the same root cause. Vague symptomatic bugs should be avoided whenever possible, because you get a dilution of the useful information in them as people report many unrelated symptoms that have a similar profile. The memory allocation problem thought to be described by 2005 was fixed, and that's why 2005 should stay closed. It's fine that this has resurfaced as a new bug, and Kelly even encouraged me to file it as a new bug since I asked him specifically about whether to file it as a new bug. So..let me get this straight. We all showed up, right after havok 4 was rolled out....and we were covered in red spots. The first person they saw, they diagnosed with measles...went out and cured measles, and gave us all the cure. When I come back the next day and say.."Hey, how come I still am covered in red spots" and try and get treatment, they suggest that they have already killed my measles..that I never said anything about it being smallpox, no one else has smallpox, and I must have self inflicted the smallpox, and I should be grateful they cured my measles in the first place? _.
It was not a "previous" bug. In fact..after the rollout of the original "fix" for 2005..not a single thing changed in my region. My symptoms did not get even a little better. In other words..I never had measles. I never reported measles. I was describing smallpox from the start. Maybe not very well, but then again..I'm not a doctor. Do I have a case for malpractice? And how about the other guy with smallpox, who came in the next day....with a very good description of what smallpox is like (2055), who is still sitting in the waiting room? _ I have to vent a little. By having me give up on my orginal report (2012), I've spent the last 3 weeks bugging my landlord, my co residents, tearing down the entire region, and filing tickets with tech support and my landlord using live chat and concierge services. That's a lot of wasted time for me, my landlord, and LL staff other than the developers, when a simple "oops, looks like many of you have smallpox instead of measles, so we will start working on that now" would have sufficed? Did it really take almost the entire month of April to see the epidemic wasn't cured in the first place? Not when they started to be told about it the next day...no. That was pure hubris. I'm done venting. I'll leave this for real work. I have a resident who keeps "bugging" me and I feel for her as we are seeing the same on a number of our own openspace islands and I'm at a loss to be able to help her - makes me feel I have let her down. Support have shown up and told us there is not an issue. Maybe they should try living there for a while. Not sure what Kelly means when saying on openspaces it shows up at lower load levels - comparing % usage (prims scripts...) these openspace ones seeing issues are empty.
We've asked if there are scripts we can run to feed back information to help identify the issue and have been told they have enough information already. Not sure anyone is looking at anything - jiras stay unassigned and support tickets are not looked at until you bug them on live chat Come on LL - you encouraged us all to go out and purchase openspace when you allowed them to be bought individually rather than as a pack of 4 - can you now support us in getting this fixed. We are looking into this and other simulator performance issues. We have been looking into these issues and I am sorry I don't have any better or more specific news on it.
The memory issue was a large enough and pervasive enough issue - it effected every open space region - that it was extremely difficult to track down or diagnose any other performance issues while the memory bloat was in place. As soon as the fix was released many performance problems were resolved, and at the same time it became apparent that there are more issues with performance and 'cyclical time dilation'. We are and have been investigating these issues from the day we pushed out the memory fix. If I implied or said that the issue was only you, I apologize. My intention was only to focus effort on the other bugs into separate jira issues, I believe I even reopened your bug and commented specifically on it. For your red spot analogy it isn't far off. We had an epidemic of measles , we didn't just see one region with the memory issue. We investigated many, many performance issues and the memory bloat was an issue in every one. The twist to the analogy is that after we cured you of measles it turns out you still have red spots from something else and we need to cure that. We couldn't tell - because you also had measles, because everyone had measles. I have had the same thing happen just after creating an OS Sim, two other sims that were just created through the new land store do not seem to be having this issue. Belinda Linden asked me if I had a rezzer on the sim, as "Sionnach" was getting scripting spikes. I wasn't sure how, there was nothing there yet. except me. I logged in with an unscripted alt just to verify that I wasn't the culprit, non-the-less the symptoms remain. Needless to say I would like to leave it empty, but after 3 days and no contact from the Lindens after putting in a ticket for performance issues, I decided what the hey, might as well try to get some work done. Heck I have been in far worse situations.
Not a rant this time..just reinforcing something mentioned earlier, and is implied in other comments. None of the support channels seems to have been aware that this issue even existed. If the developers have been "investigating" for well over a month now...why is it none of the support channels as mention in any of the comments been aware of it? Can you imagine the number of hours saved, and attention given to other items, if the support people had been able to say "Yes, we are aware of this behavior, and our developers are working on it". Probably well better than 90% of the residents would not know what cyclical time dilation was if it crawled up on their lap and called them daddy. They just know that lag has sometimes been worse recently, for no apparent reason..and are getting angry and snappish again. A quick look at blog posts will show you this. The tone is getting unpleasant again. It had, with the usual exceptions, been a little more civil for a while. As much as we hate being told "we know something is wrong, and we are looking into it..", we hate way worse when we are told 'we have no knowledge of any problems like this anyplace else, check your scripts and objects" (a common support response).
Maybe now that they have actually assigned an Issue number to it this information will be passed along to support. I have to be honest....not seeing an issue number until now leads me to believe that not much has been being done to alleviate a problem that it has been suggested affects everyone to a greater or lesser extent. Thanks Alexa for linking these issues.
The internal issue linked is not a new issue, and is actually only one of a few internal issues we have tracking this and similar performance concerns. I just recently purchased an Openspace sim and did some data collection. The openspace sim was completely empty except for a single prim containing my monitoring script. The script took time dilation samples every second, noting the best and worst values. A counter also kept track of the number of times that the time dilation was below 0.90 during one of these samples. Over a 3 hour sample period the data for the openspace sim was:
Best Time Dilation: 1.0
For comparison I placed a copy of the prim/script in my "standard/non-openspace" sim which was not empty (11,167 objects, 192 active objects, 1272 active scripts) over the same 3 hour period of time and the data was: Best Time Dilation: 1.0
I realize a better test would have been to use two completely empty sims but I didn't have the luxury of having an empty "standard" sim. I am going to keep sampling the data for a longer period to see if the trend continues (i.e. about 4X the time dilation cycles in open space vs. standard sim). I am having the same issue with open space sims in TCH Estates
So I have been keeping my eye on this one. I noticed this was reported a month ago now. Are we making any headway on this issue, or is this something that is on the back burner. Actually it seems to be getting worse. I am noticing that unlike before TD would drop for less than a minute, now it holds at .21 for much longer. It would be interesting to see what sims I am linked to, to see if the drops happen concurrently, or if it rotates following a specific pattern or not.
Wallace, I have been watching (and complaining) about this for much longer than a month. For a long while I also thought that maybe this had to do with the other regions sharing a processor with me, but for 2 reasons this seems not to be the case. The main one being...in one region I removed everything in the region, all objects and scripts...to no effect at all. It was just as bad after as before. If it were dependent upon what was running in the regions...clearing one of them should have had some effect. The second point would be that to one extent or another..this is shown in all regions. Severity does change with server changes however. Over 3 different servers in my old openspace I had problems ranging from bad, to tolerable, to even worse on 3 different server moves...the last specifically done by concierge to not include any of the other regions I was currently sharing a processor with (at least, that's what they said they did, and my server did change). As noted..that was the worst of all. I then changed openspaces to one that was no where near as bad. That has stayed pretty good for the last week or so, but it looks like my server changed with the most recent server update, so performance has slipped a bit again with the new one. Maybe the severity has to do with what order you are booted in? ie...first region on the processor is in better shape than second region...down to 4th region being really lousy? That sounds possible to me...and would also explain why it's not as noticeable on standard regions...and so much more noticable on some openspaces and not as much on others. Might be an interesting experiment for them to check that.
As far as their working on it..I'm sure they are, although I'm not sure they have a clue. They have been awfully quiet. I see up above that yet another new issue has been opened to join the cue also. Welcome Im not expert but i know what ive seen. i know open space run 4 per cpu, and are memory alolcated. BUT my testing has showed <i have 2 openspaces on the same server> if i lag one, the other goes down with it. now take all the land groups ect and u see an advertisement that sais "SELLING CHEAP LAND COMMERCIAL OR RESIDENCIAL LOW PRIM!!!" and you think to yourself, linden lab's need to make the words "light use" a little more known as ive seen open spaces being cut into 8 plots and sold with clubs and shops on them. i think either a new method of allocating memory to openspaces needs to be created or the words Light Use needs to be capitolizes and enforced
I am seeing the same cyclic dialations (on "South") although I call them constant intermittent-server-side-lags. They were there before I put any prims or scripts on the island and they are still there now. I submitted a ticket (#4051-4822915 ) but it was not addressed.
Count us in. Lawson Landing estates and Sailors Cove Sims are experiencing the same problem all over the place. I think we have reports of that phenomenon in just about everyone of our voids. The impact on sailing is devastating especially when races are going on.
I've lost 5 tenants over this bug, that's $575/month lost if I don't find new tenants willing to put up with this terrible performance problem.
Daten, it doesn't matter. This happens to completely empty sims. It also didn't happen really prior to a few versions ago. I've had openspaces since 2006 and this didn't happen if you go back a few months. So no, this isn't just people loading down the sims. I'm not saying you can't load down an openspace, but this is on top of any of those problems. You know, would it be possible to get a mass rollback done to the open space sims only until this has been resolved internally? To pre-havok 4 where things were stable on them. Not a 'pretty' solution but it's better than doing nothing.
I have to agree, we need to move on to stabilizing this. I am all for a rollback if that would solve the issue, actually I would even volunteer my problem sim as test pilot to see if this would work. Although I am sure there are some cross compatibility issues that may prevent this.
But with recent price drops, many of our sims are already suffering from sales, add to which this ongoing problem has made owning a sim or multiple sims very risky business. Contact me in world if there is anything I can do to help lead to a quick solution. I don't know Jaxx. You'd probably have to go all the way back to Havok1 to avoid this. I don't know how willing people would be to do that, Linden or owner.
Thats actually what i'm proposing... H1 reversion.
Kelly re-assigned this to me, as I'm actually the person who's investigated this problem the most.
First, a reversion to Havok 1 just isn't going to happen. That version is too old and crash-prone to be useful. So we need to fix this problem in another way. In my investigations, I've found that the most of the delays are NOT Havok related. If you monitor the stats as Kelly instructed above, you'll find the time is not being spent in the physics area. There are a bunch of things that seem to cause problems:
FWIW, today's rolling restart has a memory leak fix in it, so hopefully that will make a small improvement. Repeating what Kelly said, we're aware of the problem and working on it. There is no single, magic solution here, but rather a bunch of inter-related issues that are hard to fix. We definitely want to make this better. Thanks Simon, but I don't think anyone has actually come out and said this is havok 4 related. All we are saying, is that this began (in a very noticable way) with the havok 4 rollout. We are not developers. We don't know what is causing things. But, we can point to when it began. Quite easily. As to your points.
1) So what. Do you mean people are rezziing things in a predictable pattern of time on openspace regions? All of them? Wow. If not, I see no bearing on this issue. 2) Thank you for the optimizations, but again, I don't see how it has a bearing on this easily seen cyclical problem. 3) And this extra memory usage is cyclical? Could be I suppose....each region saving simstate each X number of seconds. 4) You are not actually suggesting that before we were crashing anywhere upwards of 30-60 times an hour, are you? 5) Ah..at least this seems to the point. Almost. But, you seem to want to blame "more openspace sims" as a cause. I was on an openspace sim before the havok 4 rollout, and the day of the rollout, the problems began. Unless there was a major increase in openspaces in those few moments, I respectfully find a logical fallacy in that also. It did not take more people using openspaces to become aware of the problem. It happened directly and immediately upon havok 4 code release, whether or not it had anything to do with havok 4 or the physics itself. That being said..the rollout previous to todays (1.22.1) did somewhat ease the symptoms on my region. ie...the time dilation does not drop as low or stay down for as long as it did before the rollout. This could just be because I ended up on a different server with different regions, or I came up first instead of last in the region sequence when the server booted, who knows. It seems that this was not the case for others following this issue. On the downside, scripts now seem to run much slower...but again...maybe that is just who I'm sharing a processor with (see, I do take that into account..._) I will be an interested observer in what happens after todays rollout. Maybe it's something as simple as the mem leak you fixed. That would be nice. I think the reason people think there might be a simple solution is that there is such a sharp transition between good and bad performance, e.g. from 1.0 time dilation to 0.2 time dilation and back again, for at least that part of the problem.
If it were a bunch of different and uncorrelated problems causing the performance decreases, you would not expect to see these sharp episodes. Sharp episodes suggest that some specific thing is happening during the episode that then stops happening so that the performance pops up to normal again. It is hard to understand why a bunch of different factors would result in such a correlation that you'd see episodic behavior. Simon,
Can you confirm that a server with 16 empty openspace regions does not exhibit any periodic time dilations? Feedback on Second Life Server 1.22.2.89099 update: The cycling has increased to a faster rate. My sim "South" was seeing aprrox. one minute cycles, now they occur every couple of seconds. And they are hard cycles down effecting not only movement but now sound.
"We definitely want to make this better..." said Simon Linden almost 2 months ago. Might I mention that just because we don't comment every day doesn't mean we have forgotten either? It still exists. It would be nice to know if anyone is still actively trying to resolve this...or if it's just become one of the "things about the SL code that we have to live with"....
I agree. I am concerned that they have given up trying to resolve the problem given the information now against openspace sims. https://support.secondlife.com/ics/support/default.asp?deptID=4417
 it was updated in June this year I'm sure this paragraph is new, or totally reworded making me worried they don't support openspaces for anything other than nothingness. The comment about not responding to performance issues oif used for nothing more thatn openwater or scenic woodland. If that is the case it was a very good con to get us to buy them.
"It is therefore important to understand what these regions are. They are provided for light use only, not for building, living in, renting as homes or use for events. As a stretch of open water for boating or a scenic wooded area they are fine, but we do not advise more serious use than this and will not respond to performance issues reported should you not use them in this way." If only the old definition of openspace was still there. I'm still confused as to why 4 share the same CPU why we can get upto 1/4 stuff on these that we can get on full. Well maybe a little less given the overhead of running the 4 but not what we actually see Thanks zinbaco..that about explains it. First they raise the prim usage, to make them worthwhile for people to buy and rent, then they tell you "just kidding...if you use them we won't support them, but we already have your money..hahahahahaha". Note they didn't bother to mention their wording change here..where they knew there were at least 100 customers paying attention. Keep them hanging around and paying for useless regions for a few more months in the belief that LL was actually working on the problem. Bah!
That paragraph was there way before the prim limit increases, and way before this bug.
Linden Lab does take time dilation that hits even empty regions seriously. With this bug, openspaces were not even good for open water for sailing. On that note, I'm not seeing this bug as much anymore. When this was filed, all openspaces, even large samples of empty ones, we dilating down to < 0.20 every 2-10 minutes. It was very noticeable. Are you all seeing this, or just general lower performance (which is to be expected)? Gigs..that paragraph read a bit like that..but it has been strengthened since I last read it...really it has. It was always suggested for light use..but it now suggests that anything other than usage as a scenic ocean sim is unsupported. And yes..I have seen some used as camping sites...with dozens of avatars just sitting around. To me, that is clearly affecting any other sims partnered with it...and is an abuse, and should probably be treated as such. I see no reason to pro-actively tar all low use sim users with the same brush. Remember, the usage that many of us used them for worked fine before the release of 1.20...and this problem only began to occur with that release. It is not a viable response to blame the users of the regions for doing exactly what they did before you changed something. That's what bugs me. They are set up and provisioned to work at the level of a quarter region, they were used like that with no problems before 1.20, and I find it reasonable to expect that they should continue to be able to be used in that fashion.
I changed regions myself...finding one months ago in which it was there, but no where near as bad. In the past few weeks it has gotten worse, although still not as bad as it was when I first reported it. I would guess that as my region moves from server to server, finding itself with different partners, as it were, that the noticeability of the problem varies. Oh...and why should generally lower performance be expected? Sounds like you are at least as cynical about the possibility of change for the better as I am.... Yes, I see this issue daily. It used to be really bad where it was not possible to fly or move. When the dilation occurs while sailing, the boat sinks to the bottom for several seconds to a minute then pops back up. It has changed in the sense that sometimes the cycle once every 10-30 minutes, but when the dilation happens it stays that way for 5-10 minutes. Then other times there is a more frequent dilation throbbing. In all cases the FPS drops to <3 and movement, either walking, flying of vehicles moving, gets very jerky. My openspace SIM, Aear Iant, has around 1000 prims with a script load of 0.4ms. This is very light usage. It runs smoothly up until the dilation intervals. I also see this problem in all the other openspace SIMs I have visited. I also see this cyclic problem on full SIMs, though it is less intense.
"Oh...and why should generally lower performance be expected?"
Are you serious? 16 sims on a single system vs 4... of course the performance won't be the same. "Remember, the usage that many of us used them for worked fine before the release of 1.20...and this problem only began to occur with that release" It started with Havok4. "I find it reasonable to expect that they should continue to be able to be used in that fashion. " Sure. And BTW, having the activity of one SIM significantly affect the activity of other SIMs demonstrates a broken scheduler. With proper reserves and/or caps, a decent scheduler can limit the impact of one set of grouped threads on another group. This is known art.
Gigs..I was thinking lower performance on open space sims than before 1.20 (which was Havok 4). Of course they will be lower performance than a full region..we know that going in. It's the "lower than it was when we first got them" that's the bothersome part.
I also reckon that paragraph is way "stronger" as you put it than it used to be. The not for residential use I'm sure is new. And if they are for nothing more than empties why on earth raise the prim count to make them "usable".
this issue was first raised in April - when did Havoc go out I've tried searching for the release note but can't find it? I'm sure these problems were from before Havoc. Maybe it was the prim count update that screwed it up as that was to take place around 31st March - bad calculations on LL behalf ?? and I do wish you could just pay the difference and upgrade an open to a full rather than having to trade 4 in. After all when you restart an open it switches server automatically so why can't you upgrade via a manual process here is an interesting thread on the forums
http://forums.secondlife.com/showthread.php?t=272219 "Performance Comparison: Openspace vs. Regular sims" OpenSpace/void sims are hosted together with 3 other OpenSpaces on the same CPU core, right?
Maybe you should find out which other openspaces run on your openspace's CPU core, and see what's happening there? @bitova loon, I think the people here know that the performance is lower, but it shouldn't be that bad..... – Chris seems like a plan Is there a way to find out which 4 share the same CPU - we have 14 open spaces which are all on different servers never mind the CPU which I'm not sure how to determine - is there a script needed for that ? Then how to find the others. Some central list somewhere just until we find the groups.
In one of the forums I understand there is an attachment to wear which writes sim information back to a database somewhere. Maybe if we get co-ordinated so one day we wear the attachment and visit all our openspaces to find the 4 "CPU mates". Then don't restart the sim until the performance has been tested as it then moves to another server... One way to improve performance on a bad day if your neighbours are causing hassle ?? and yes the performance can be that bad although I do have to admit it has not seemed as bad recently. I have some cartoon animals that can cripple an open - they are now banned into my inventory Zin No, that's ludicrous.
Why should we have to try to figure out what the other 3 regions are on our CPU to test this? Linden Lab can easily create a set of openspaces isolated onto a CPU for testing on aditi. I asked them weeks ago if they had benchmarked whether this was happening when every sim on a CPU was empty or not, and they haven't replied. We shouldn't sink hours of work into this if Linden Lab isn't even willing to sink a few minutes into it. In a way I agree except LL have had since April to try this - set up 4 opens on the same CPU and a standard then run the tests and publish. I think they are beginning to regret upping the visibility and prim counts of openspaces therefore making them more usable, so now not spending as much time trying to fix the problem hoping to swing the balance back into standards.
From what everyone was seeing, the upgrade to Havok 4 did this, not the prim increase. Of course, we'd know for sure if we had those benchmark numbers.
No, it's 4 full SIMs per server and 16 openspace SIMs per server. We don't need further evidence - The LIndens know well they have a thread scheduling problem. BTW, the 1.24 rollout makes this dilation cycling worse. I now nearly stop moving for several seconds when the time dilation drops to 0.2 and stays there for quite some time. Otherwise it's at 0.99-1.00. This is on an openspace SIM with a acript load of 0.6ms. I also see this problem, though less severe on full SIMs now.
Updatig the version # to 1.24..
You are at 142663.6, 271566.9, 17.1 in Aear Iant located at sim8005.agni.lindenlab.com (8.10.149.72:13006) I was on a stable host until last Saturday (9-3-2008) when the sim was reset by LL for maintenance. Support noted that this reset was to shift to a new VPN.
Since that reset, I have not been able to find a stable host. The time dilation is the worse that I have seen it on all hosts. There is not a stable host for openspace sims on the grid. This is starting to get really bad. I am seeing wild swings in time dilation on a fe full SIMs. Lag is way up, TD cycles from 1.0 to 0.2 periodically.
Specifics: "The Faery Crossing" and "Madrigal". I disabled the top 5% scripts that contributed 50% to the 5ms load. No effect. I disabled all scripting by estate tool, tested that the scripts were indeed inactive, and... no difference. I disabled all collisions (though none were being reported), no difference. The cyclic lag is terrible. I did notice that SIM ping cycles too, at times almost 1.0 seconds. Now that is entirely the network's contribution. And yes, I restarted the SIM several times looking for a better hosting server, haven't found one yet. So, this problem, which plagues openspace SIMs from time to time seems to have migrated to full SIMs too. I forgot to specify which hosts: 3420 & 2420.
I thought it was just opens which were rehosted on a restart. Fulls I thought did not change.
We've also spotted a huge performance decline on our full sim recently, really ever since the mono release to tje point of not being useable at all. We had not thought to check the dilations as the root cause rather had associated it with the mono code. Now off to check. Zin Zin, full regons hop when restarted.
The problem still occurs. Any updates on this problem. It is annoying having airbrakes applied from time to time, and I would like to know if this is to be the status quo for SL. sim8166.agni.lindenlab.com (8.10.149.233:13008) Well Balpien...nothing has been done on this since..oh....April or so. Does that answer your status quo question? I have long ago now assumed that they know what the problem is..have no fix for it, and won't acknowledge that this is the case since then they would have to admit that they are continuing to sell a defective product (ie..openspace regions). Actually..they do know it's defective..they have admitted that the problem exists...yet I'll bet they don't warn new buyers that they will be subject to cyclical lag...and there is nothing they can do about it. Business as usual in the world of the corporations...or..maybe I should be less cynical and understand that it really does take more than 6 months to read and compare a couple of server logs......
I'm running about 2 minutes with a TD at or near 1.0,0 followed by about 30-60 seconds of .2 TD . Almost like clockwork and disabling physics, collisions, and script has no impact; even with script enabled, I'm only running 1 ms total. Any Lindens around to update this issue?
----------------------------------------------------------------------------------------------------------------------------------------------------------------- You are at 149257.5, 258244.4, 2.0 in Maridhoo Island located at sim7800.agni.lindenlab.com (8.10.148.39:13009) Second Life Server 1.24.9.98659 ----------------------------------------------------------------------------------------------------------------------------------------------------------------- Out of curiosity, if people can elaborate on the IP addresses of their sims, and the IP addresses of adjacent sims (this can be found by going into the simulator and clicking Help>>About Second Life), it might contribute some additional information on the cyclical lag issue.
From north to south on the grid: Undine Straight (open space) - 8.10.148.*** I noticed the cyclical time dilation problems occuring most frequently when one of my open space simulators was on a different subnet as the sim next to it. When all of the adjoined simulators were on the same subnet, i never experienced a cyclical lag issue, other than the usual reduced performance due to being on the same core as 3 other spaces. I'm beginning to think these cyclic time dilations are caused by the simulator taking perodic checkpoints. Given the other host of bad sclaing designs throughout the SL codebase, I will venture to guess that checkpointing is performend under a global lock, hence it affects all the simulator instances running in a server.
At this point it is now impossible to determine what is going on given that my TD sits around 0.1 more than half the time now. Probably people demonstrating what a real overload on openspace SIMs looks like Mifune, I'll check that observation about different subnets. Oh well, I just gave up my OS sim, s I am unwatching. BTW, with only 55 objects, 10 scripts, max load of 0.1ms, the cyclic dilation still happens on my ex-OS sm..
Jacking up the prices and forcing most people to abandon OS sims is not fixing the problem. Since you're planning to continue to sell this expensive boutique product as Homesteads sims, you need to implement a technical solution for those handfuls that plan to use them.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Open
Critical
Cyclic time dilation especially apparent on openspaces.
I raised a JIRA for that one too.....
I saw it on Annet a couple of days ago even after the sim was clear of prims and restarted more than once. I spoke with Dee Linden about it in LiveChat but of course the sim behaved itself perfectly when Dee was there.
Today I am seeing the same thing on Gugh.
The symptom is that time dilation drops to 0.20 and stays that way for some period of time. Sim FPS drops too then. It happens periodically and is very noticeable whilst flying across a sim. The rest of the time the sim performs beautifully.
Possible workaround: have Dee Linden on all open space sims at all times. j/k