Moon Metty

Hi Louise, The chatlag problem (BUG-2406) isn't something that LL can fix by doing something technical. Of course LL could pick up the phone, or send a mail to the faulty relay station. I've tried to talk to my provider, but they can't be bothered. Computer says no ... ======= Hi Maestro, My compliments on script performance! I don't think I've ever seen Egglebury run so smooth.

Hi Louise, As you can see on the jira, I'm having the same symptoms. Our traceroutes have one line in common: xe-5-3-0.cr2.lga5.us.above.net [64.125.25.57] That thing (somewhere on the US east coast) is broken!

Hi Gadget, "Accepted" means that the bug is confirmed. "Released" means that ummmm ... the bug can roam freely in its own antfarm, lol. (It's nonsense) As a source of information for residents, the jira has indeed become worthless. Also, release notes will be more cryptic than ever, without link to what was wrong in the first place. Oh well

This jira is just over a month old .. https://jira.secondlife.com/browse/SVC-8182 https://jira.secondlife.com/browse/SVC-426 is slightly older.

Yes Hitomi, Even under these terrible conditions, Qie has managed to find griefing objects, each with 280 scripts inside ...

Actually, maybe we're looking at griefer objects, each containing 280 malicious scripts.

Please see https://jira.secondlife.com/browse/SH-3055 Grumpity ProductEngine added a comment - 28/Sep/12 8:39 PM 3.2.4 has been temporarily unblocked.

Hehe, ok Ayesha. In the most simple words: If your region is in this state, it needs a restart, lol. But I know you're not the dunce you claim to be! On a healthy and well managed-sim each script gets a turn each frame, 45 times per second. If there's time dilation, the frame rate drops. Then scriptspeed drops too, but it's possible that scripts still get a turn each frame, right? On the affected regions we see here, scripts only get a turn every 560th, 844th, etc frame. The pattern is clearly in the frame numbers, not in the realtime measurements. So there must be some process on the sim that counts to 280 frames, and it's probably somewhere in the script engine. We don't know the inner workings of the server, but for a developer this pattern can be a nice clue.

There's a pattern in how affected regions behave. You could call this script a "patient timeslice counter", lol. default { state_entry() { llResetTime(); frame = (integer)llGetEnv("frame_number"); region = llGetRegionName(); llOwnerSay("Region " + region + "\ncurrent frame: " + (string)frame + "\nNo lag uptime " + (string)(frame / 162000) + " hours"); while (TRUE) { llSleep(0.0001); integer new_frame = (integer)llGetEnv("frame_number"); integer elapsed = new_frame - frame; if (region != llGetRegionName()) llResetScript(); if (elapsed > 45) { llOwnerSay("FPS = " + (string)(elapsed / llGetAndResetTime()) + ", Frame = " + (string)(elapsed)); } frame = new_frame; } } } It shows the FPS, and how many frames go by before the script gets a turn to run. "No lag uptime" means the time to reach the current framenumber in perfectly lagfree conditions. ======= [8:09] Object: Region Serpentata current frame: 3902516 No lag uptime 24 hours [8:11] Object: FPS = 21.119050, Frame = 1960 [8:12] Object: FPS = 18.227080, Frame = 1960 [8:14] Object: FPS = 21.051160, Frame = 1960 [8:14] Object: FPS = 22.998090, Frame = 358 [8:16] Object: FPS = 20.837030, Frame = 1602 Note that 1602 + 358 = 1960 again ======= [8:25] Object: Region Nolidae current frame: 3922795 No lag uptime 24 hours [8:27] Object: FPS = 18.511800, Frame = 1961 [8:28] Object: FPS = 22.537040, Frame = 1961 [8:29] Object: FPS = 23.074650, Frame = 853 [8:30] Object: FPS = 22.631170, Frame = 1108 [8:30] Object: FPS = 18.577030, Frame = 843 [8:31] Object: FPS = 18.575690, Frame = 1118 Note: 853 + 1108 = 1961 and also 843 + 1118 = 1961 Two different regions, same numbers. ======= [7:04] Object: Region Turnip current frame: 24305650 No lag uptime 150 hours [7:05] Object: FPS = 18.101890, Frame = 1400 [7:07] Object: FPS = 20.265610, Frame = 1400 [7:07] Object: FPS = 26.697500, Frame = 591 [7:07] Object: FPS = 23.388500, Frame = 809 [7:08] Object: FPS = 18.943070, Frame = 591 [7:09] Object: FPS = 17.409910, Frame = 809 The magic number for this region is 1400. ======= [6:53] Object: Region Eggar current frame: 37910844 No lag uptime 234 hours [6:53] Object: FPS = 26.012590, Frame = 1123 [6:56] Object: FPS = 26.867400, Frame = 1122 [6:57] Object: FPS = 20.847310, Frame = 909 [6:57] Object: FPS = 18.683490, Frame = 213 [6:58] Object: FPS = 18.166260, Frame = 907 [6:58] Object: FPS = 25.348190, Frame = 213 [6:59] Object: FPS = 26.396440, Frame = 910 [6:59] Object: FPS = 21.316050, Frame = 214 All very close to 1122. ======= [8:41] Object: Region Laserlight current frame: 5379152 No lag uptime 33 hours [8:42] Object: FPS = 17.480940, Frame = 843 [8:43] Object: FPS = 16.642640, Frame = 845 [8:43] Object: FPS = 18.821870, Frame = 508 [8:43] Object: FPS = 16.920500, Frame = 335 [8:44] Object: FPS = 19.506290, Frame = 506 [8:44] Object: FPS = 15.175480, Frame = 339 Here the number is 844. ======= [5:47] Object: Region Highflyer current frame: 3948278 No lag uptime 24 hours [5:48] Object: FPS = 17.933130, Frame = 560 [5:48] Object: FPS = 21.846250, Frame = 561 [5:49] Object: FPS = 19.775010, Frame = 961 [5:49] Object: FPS = 17.722290, Frame = 160 [5:50] Object: FPS = 21.606740, Frame = 392 [5:50] Object: FPS = 22.683760, Frame = 169 [5:50] Object: FPS = 22.873470, Frame = 560 Note: (961 + 160) / 2 = 560 and also 392 + 169 = 561 This sim's number is 560. ======= 560, 844, 1122, 1400, 1961 .... What do these numbers have in common? Well, they're all multiples of 280. Sorry for the lengthy post.

Thanks for the explanation Oskar. So the name is spelled "Pathfinding Release Channel", but it's pronounced "Second Life Server". It's not a problem, as long as the channel takes part in the regular deploys. It was interesting to see the region run so smooth after 30 days of uptime, though.

Hi Oskar, Egglebury was indeed restarted, it's now running Second Life RC PF 12.09.07.264510 The server version is up to date, but does "RC PF" still exist? I mean, if there were fewer release channels, there wouldn't be so many of them, numerically speaking.

Hi Oskar, Last week I asked you about the region Egglebury. http://community.secondlife.com/t5/Second-Life-Server/Deploys-for-the-week-of-2012-09-10/m-p/1667993#M7480 Today the region has been restarted, after more than 30 days of (amazingly smooth) uptime. The problem is that Egglebury is still running RC PF 12.07.31.262785, an ancient version. So it looks like one on't cross beams gone owt askew on treadle.

Hi Oskar, Can you please wave your magic wand over Egglebury? The region appears to be running Second Life RC PF 12.07.31.262785 The last time CHANGED_REGION_START triggered was 27 days ago. Yet, looking at sim performance, it's as if the region was restarted a few days ago. It's a mystery to me ...

* Scratching head * https://jira.secondlife.com/browse/SVC-4968?focusedCommentId=343620&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-343620 Here Baker Linden asks you to: - Download and install a special beta viewer. - Go to the beta-grid. - Send bugreports by IM.

I will charge 1000 L$ for the next bug I report.

Gathering new bugreports in a central category could be a good idea for less experienced users. Making all new jiras invisible to the public (or even closing comments) is ... simply insane (thanks for the words, Qie). What does a company do when it has trouble communicating with its customers? Well, apparently the cheapest way to address the problem is to stop communicating. It's clear that this decision was made by people who are clueless, helpless. ======= I guess this is a good time to remember STORM-560, to show how painful a Jira can be to the Lab. What happened here? Throughout the early testing stage people complained. The answer was: "It works as designed." In public beta people complained. The response was gibberish. Of course people kept complaining after the release. "This jira is a drama bomb!" The real drama bomb was dropped here: http://community.secondlife.com/t5/Tools-and-Technology/Check-here-if-you-want-more-options/ba-p/664486 And then, it took a dev not more than one and a half day to fix the problem, after the key Linden apologized: "... because I misunderstood the behavior ..." Noone ever complained afterwards, though there are still some minor issues left. These minor issues are mentioned in STORM-560, and I doubt anyone will ever report them again, considering the impending changes. Anyway, no matter how painful it was at the time for the Lab, it's forgotten, the hideous bug was fixed. ======== Here's my advice to all Lindens, for when these moronic changes to the jira have been reverted: Look closely at how Maestro Linden has always worked the Jira, and learn. (Abstract: Communicate, until it's sorted)

Indeed, the event-queue can only hold one timer event. Another detail: The timer event never triggers two consecutive available frames. The fastest rate possible is 45/2 = 22.5 events per second. This slows down further when the script engine can't handle all scripts in a single frame. I can't imagine that can cause problems on an idle region, though.

Hi Lexbot, Some time ago, we did a test to see the effect of host-sharing sims on eachother. Putting a lot of stress on one region didn't have any effect on the other "neighbouring" regions.

Hi Simon, Thank you for your clear announcement. The downsides of idling are probably negligible (time will tell, hehe). The upsides are a bit of an all-or-nothing chance, depending on which sims share the host. Will there be a mechanism to arrange sims in a such a way that quiet sims are grouped with crowded sims? Also, please see https://jira.secondlife.com/browse/SCR-332, a proposal for more detailed feedback on idling.

Hi Eve, Please see my notes in https://jira.secondlife.com/browse/VWR-20438 You can change the medium value in fonts.xml , but that will change a number of other things too. In the Jira, I also said that floating text should have a hardcoded size. I guess I was wrong, for people with wishes like yours Anyway, the XML-structure doesn't allow for a decent fine-tuning. That's what VWR-20438 is about.

Hi Jer Is https://jira.secondlife.com/browse/SVC-7231 what you're looking for? Oops, I managed to spell your name wrong, sorry, hehehe.

Hey Daral and Hitomi Yes, this bug can be triggered if the time and date are not set correctly in your computer. Unfortunately there are other (unknown) causes too. In the past, reports of this bug were all closed as "contact support". Of course that didn't help much with tracking the bug. I had to lobby quite a bit to keep SVC-4169 open. You can see by the number of linked issues that it was much more common in the past. I guess this tells us that something must have improved on LL's servers, but this frustrating bug still exists. It can haunt you for weeks, and suddenly disappear ... At least now you can say "I suffer from SVC-4169" when you file a support ticket. Whether support can actually do something remains to be seen. You could also leave a comment on SVC-4169. Even if you don't have new information to add, it's a message that the bug is still around. Well, I'm sorry I don't have a real solution for you. But as other people commented on SVC-4169: "I suppose it is a slight comfort to know others have the same issue" 

Hi Daral, The problem you're describing looks exactly like https://jira.secondlife.com/browse/svc-4169 This buggy behaviour used to occur much more often in the past. It's possible your computer-clock is set incorrectly, could you check that?

Siani, that looks just like https://jira.secondlife.com/browse/SVC-4169

Hi again Amanda To reiterate the actual point of my comment, could you say in your own words what you think our concerns are on the topic of, for example, facebook and twitter? How can we tell you're listening if you only address what you think is positive?