Ayesha Askham

Drake Your solution is in its concept simple but the application, or getting the solution applied is far less simple. Most avas are the products of ignorantly elaborate work by their RL owners, and suggestions that they simplify them simply meets with blank refusal to cooperate. Cincia In 2010 use of flexi did not seem to cause a significant issue. You are correct in that sims rarely crash now, even though large numbers of avatars are on them, though it DOES still occur, especially if, as seems all too common, certain maleficent individuals deliberately crash the sim. I my experience entertainment sim owners are rarely savvy enough to use bare sims for performances, most appear to be inordinately complex, which as you both note is just asking for trouble!

Mankind and dd There is a problem and it does not have a simple solution. The fact of the matter is that the render pipeline of SL is now far more complex than it was even two years ago, let alone 4 or 5. Each improvement to render quality in SL brings the need for more and more sim-client communication: SSA was an attempt to lessen this, but it is far too little, too late. The flow down that comms pathway is not fast enough now to carry all the information needed to render SL at the quality that most of us have come to expect, and when that demand exceeds the capacity of the server to supply it, problems will inevitably arise. I do not have a solution, nor am I sure that one exists.

Yes, Perrie, it IS possible but since it has never failed to display the restart message before, and displays other server-sourced messages, it is less likely in my opinion. Also there was nothing in the logs to suggest a client crash. It was the usual log-out greyscale image, without the message.

Maestro This issue becomes stranger the more I look into it. You say the region detected agents and DID give the appropriate warnings - this is not likely since prior to my arrival there were NO OTHER agents on the sim. I can categorically state that I received NO warning at all, not even the usual "You have been logged out of SecondLife" one, so something in the sim-client communication was decidedly not functioning. I do not say the warning was not issued by the server, but I DO say that it was never received by the client.

Whirly Unfortunately most of us cannot see BUG JIRAs, but I have observed this phenomenon many times lately while sailing. One thing concerns me. In the past if an avatar was "ghosted", despite being logged out it was not possible to log in again until the ghost avatar had been killed from the sim (usually by a restart). Is this still the case? In my innocence I thought LL had fixed this ages ago? Or is this yet another side effect of "The Interest List" code changes?

Maestro It is Woods of Heaven, now sim no. 9786. There are issues on restarted sims all over Main Server, though: I have just submitted a ticket regarding Lost Island, currently sim no. 9038 which is showing 100ms more sim ping than Woods and packet loss spikes of over 5%. About 50% of TPs from there (Lost Island) are resulting in crashes which result in me being returned home, so I am assuming that it must be a networking issue within SL for that to occur. ETA: Upon crashing during TP out of Lost Island I relogged, to find myself at home. No great surprise there. I spent a few minutes dealing with messages and then logged off. (In order to forestall comments, it was a clean log out - no signs of any sort of viewer crash). I was rather surprised to be logged in, when I returned, to Lost Island, where I had crashed earlier. This, Linden Lab, is NOT amusing. To be honest I did not even think it was possible! Maestro, something is very wrong. Please get it sorted. :smileysurprised:

OK an update. The weekend seemed to suggest all was back to normal, no packet loss and sim ping back to c.170ms. Of course there was little or no commercial net traffic. Last UK evening the gremlins were back: sim ping climbed to 270ms and packet loss 1%, not prohibitive but useless if you do anything that requires a fast response time. I tried contacting Abovenet support a couple of days ago, but so far I have had no response whatsoever. ETA at 4:30pm BST Tuesday: Sim ping is rising again, 250ms and counting. Packet loss has begun again. Looks like we are in for a rough patch. Having observed some anomalous behaviour within SL after today's restarts I am not sanguine about the prospects. ETA 2 at midnight BST: Sure enough, sim ping and packet loss climbed to a peak of 300ms and 1.5% respectively about 12noon PDT and remained high until about 3:30pm PDT, when it began to return to "normal". By 4:15pm PDT sim pings were back under 200ms and packet loss had ceased. When will this trouble abate? Is SL to be handicapped for Western Europe's evening hours now? ETA 3: Wednesday 4:15pm BST: Sim ping is up above 200ms and rising again so it seems no-one is doing or no-one CAN do anything about this. Looks like SL will soon be losing another tranche of European users. oh, and still no response from Above. ETA 4: Wednesday, at about 6:30pm BST, 10:30am Pacific the sim ping dropped back to its "normal" value of around 160ms and packet loss vanished. This only lasted for about 10 minutes, then packet loss resumed and sim ping shot back up to 270+ms. So what caused this?

OK Maestro This is ridiculous. My sim just went down with absolutely NO warning. None. Now OK, I know better than to be doing anything at this time on a Tuesday, but your servers ARE supposed to give warnings, not just boot folk off unceremoniously. No, I did not log in less than one minute before the restart, though it might have been less than 5 minutes. This was supposed to get fixed. It clearly is not fixed. :smileymad: Or was this another ham-fisted shutdown by the server team?

Imagin I was asking this very same question a little while ago in the Firestorm support group chat. The consensus is that there is no-one on weekend duty with GSP posting permissions. This is by no means the first time LL have done this, and it is highly irritating but, I am reliably told, it is very unlikely that LL will do anything about it. It seems that timely reporting of work stages is not considered a priority at Linden Lab. ETA: Interestingly, it would seem that a good few folk that are able to log into SL cannot rez items or change their clothing, so it looks to me either as if the "maintenance" IS still ongoing, or when the crew knocked off on Friday they left some part of the database turned off for the weekend. How nice.

Wolf This is interesting. Yuriko Nishi is suggesting that the datacentre that you are connected to is important in this mater and it seems that Maestro has passed on our concerns about this to the LL operations team (qv the Server thread). For me tonight (UK time) ping and packet loss were back to the evening normal, ie no packet loss and sim ping anywhere from 160-200ms. I suspect I've been luck these last two nights though because others are still bad. Despite Cincia stating the blindingly obvious, I think LL are actually aware that something is awry with their internal comms.

Rick I don't know if the reroute was an attempt at a solution to the throttle/slow server issue, but for me at least sim ping was only about 25% up at most on the afternoon and I got no packet loss at all tonight in the UK, from 9pm BST until after midnight.

Maestro As you may gather from Monty, and I quote him: "For what it's worth, I've been getting 100+ mS ping times from the Linden Boston office with above.net appearing to be the culprit. I don't know the why but it is real and new." the sim ping issue has NOT gone away. There appears to be a severe throttling occurring with one of Above.net's servers in the USA, and it is affecting SL users in Europe primarily during our evening hours. I suspect US users will not notice the increase unless they look, since to my eyes, a sim ping of less than 150ms seems to make little or no difference. Our daytime (2-6pm BST) sim ping is normal at around 160-180ms, but from 9pm -12midnight our time it is 280-350ms with some spikes of high (>10%) packet loss (up to 2% average for me as against 0 in normal circumstances). The consequences of this are not severe if I am not moving, apart from annoying chat-lag, but if any movement is required the increased delay becomes a serious impediment. The co-incidence with the Main Server roll on Tuesday is to say the least unfortunate and I do wonder if the extra data that sims are sending is exacerbating the problem. In short, this is a matter that needs sorting out.

Re this sim ping issue: I am now pretty sure that it is not merely SL users that are causing this problem, the increase and decrease in sim ping and its concomitant packet loss is tied in with general, (ie business-related) internet traffic across the Transatlantic link during the US working day. I must assume either that we have reached traffic saturation on the cables, or one or more is down at the moment. @Hitomi, I have no idea what a VPN is and I doubt if I could use such a thing anyway with my VM modem.

For two nights now and ONLY at UK night, sim ping and Transatlantic ping is 50% greater than daytime. It appears, from using tracert to be above.net again. I am not blaming Linden Lab for this, it is beyond their control, but is there anything those users like me in the UK who have seen this issue a few times lately can do about it? I usually see a sim ping at home od between 165 and 190ms, tonight and last night after 1pm PDT it is up to over 300ms, and packet-loss is spiking at several percent, averaging at about 1%. This makes SL very laggy and difficult, since response time is so poor. Anyone know a solution, apart from RL?

For two nights now and ONLY at UK night, sim ping and Transatlantic ping is 50% greater than daytime. It appears, from using tracert to be above.net again. I am not blaming Linden Lab for this, it is beyond their control, but is there anything those users like me in the UK who have seen this issue a few times lately can do about it? I usually see a sim ping at home od between 165 and 190ms, tonight and last night after 1pm PDT it is up to over 300ms, and packet-loss is spiking at several percent, averaging at about 1%. This makes SL very laggy and difficult, since response time is so poor. Anyone know a solution, apart from RL?

Maestro It is very much a "first look" opinion, but it rather seems as though the new Server Version on Main Server has caused a bit of a step-back in progress on the "Interest List" prim-rezzing issue. I did think that there was some increase in bandwidth after TP to several Magnum regions last week but I was unsure. The issue seems to be present now on Main Server so it must be related to the software. Some increase in sim-client communication, but not anything that the client can handle, it would seem. Once I have more information I will post again and file a JIRA BUG-report. Reason for edit: Grammar and spelling correction.

[UPDATED] Scheduled Inventory Server MaintenancePosted by Status Desk on September 11th, 2013 at 06:30 am PDT [UPDATED 6:30 AM PDT, 11 September 2013] Today’s Inventory Database Maintenance is underway. [POSTED 4:15 PM PDT, 10 September 2013] We will be undergoing scheduled inventory server maintenance Wednesday September 11, 2013 beginning at 5:30 AM PDT. During this time, some residents will be logged off and will be temporarily unable to log in for a brief period. This maintenance may disrupt transactions and logins. Please check back here for updates. It is now past 1pm PDT and this maintenance is not "Resolved" or "Completed". So it is still on-going?? Wow! ETA [POSTED] Scheduled Inventory Server MaintenancePosted by Status Desk on September 11th, 2013 at 04:08 pm PDT [POSTED 4:08 PM PDT, 11 September 2013] We will be undergoing scheduled inventory server maintenance Wednesday September 12, 2013 beginning at 5:30 AM PDT. During this time, some residents will be logged off and will be temporarily unable to log in for a brief period. This maintenance may disrupt transactions and logins. Please check back here for updates. I guess that answers my question...except when did the tekkies knock off today? Or have they not really stopped? It would be nice to know if some of the folk I had expected to meet inworld tonight had actually not been able to log in. 2nd ETA: Yes, I AM aware that the time the first session apparently finished was added to the entry courtesy of some neat Ninja Editing. WTG GSP...Time travellers!

[UPDATED] Scheduled Inventory Server MaintenancePosted by Status Desk on September 11th, 2013 at 06:30 am PDT [UPDATED 6:30 AM PDT, 11 September 2013] Today’s Inventory Database Maintenance is underway. [POSTED 4:15 PM PDT, 10 September 2013] We will be undergoing scheduled inventory server maintenance Wednesday September 11, 2013 beginning at 5:30 AM PDT. During this time, some residents will be logged off and will be temporarily unable to log in for a brief period. This maintenance may disrupt transactions and logins. Please check back here for updates. It is now past 1pm PDT and this maintenance is not "Resolved" or "Completed". So it is still on-going?? Wow! ETA [POSTED] Scheduled Inventory Server MaintenancePosted by Status Desk on September 11th, 2013 at 04:08 pm PDT [POSTED 4:08 PM PDT, 11 September 2013] We will be undergoing scheduled inventory server maintenance Wednesday September 12, 2013 beginning at 5:30 AM PDT. During this time, some residents will be logged off and will be temporarily unable to log in for a brief period. This maintenance may disrupt transactions and logins. Please check back here for updates. I guess that answers my question...except when did the tekkies knock off today? Or have they not really stopped? It would be nice to know if some of the folk I had expected to meet inworld tonight had actually not been able to log in. 2nd ETA: Yes, I AM aware that the time the first session apparently finished was added to the entry courtesy of some neat Ninja Editing. WTG GSP...Time travellers!

We come back to this topic time after time. Firstly, and it is a case of stating the obvious, Linden Lab will NEVER publish the reason for an outage if it is in ANY way security related. To do otherwise would be just plain foolish. The real bugbear for those of us that visit SL regularly and frequently is the unreliability of posts to the Grid Status Page, especially Restart notices and the like. Recent experience is that posting to the GSP is erratic and frequently inaccurate. Sometimes changes to operational schedules are unavoidable, and communication of those to users is important. Not, perhaps if you have just come to SL for some casual cyber-sex of to play a war-game, but if you are trying to do something constructive or creative and have perhaps only a limited time-frame in which to do such things, such information is important if not vital. Unfortunately the chaotic nature of internal communications at Linden Lab works counter to this and despite the best efforts of several folk at The Lab, the GSP remains unreliable. Qie's point about rolling all channels on the one day would be fine, were it not for the fact that the Server Team have a lot of machines to restart and mistakes are made far more often than would be acceptable in many industries. Giving them a 20% increased workload on a Tuesday just seems to be asking for trouble!

I'd guess the message that the "Unscheduled Maintenance" was complete really meant "We have done all we can to fix it for now". I believe it is Labor Day in the USA today, so it is likely that the needed techs are not around. I'd give it another 24 hours. I've seen a few oddities around myself today so it clearly isn't 100% fixed. FWIW, I think that some of this problem is that while SSA clearly has worked well, probably better than the LL programmers had expected, the longer sims run it the more anomalies will crop up. Some of SL's servers are pretty creaky at best, so this new code, which is lighter on client systems, but heavier on sim servers, is causing some servers to fail.

Rick Second, third and fourth chances have been offered and squandered. This issue with the GSP has been going on for months, the RC Roll error was just the latest in a long line. Not easy? It's not that hard, man!

Darien I refer you to Perrie's post. Firstly with regard to bandwidth, there is absolutely no point in setting your viewer bandwidth greater than Linden Lab's server capacity; all that will happen is the the viewer will expect more data than it is receiving and errors will occur. You must surely have noticed when Linden Lab began to reduce their server output rate? Secondly with regard to wireless routers: they transmit data in discrete pulses, and while the best are getting faster the vast majority of routers used are still slow, so 500bps is a sensible compromise. Thirdly as to who started this "myth": it was begun in Linden Lab's own wiki and has been circulated by TPV support groups throughout SL. It is NOT nonsense, I have verified it with several viewers over the years including the Linden "Official" viewer. If I am wrong, I am sure someone inworld will berate me, but in all truth I do not expect to be proven wrong in this matter.

Dezy That is great news. I didn't want to implicate your ISP since I don't know whereabouts in the world you are, but I've had issues like this myself before - I am in the UK. As to your CPU, Yes, my error, it ought to be up to the job, I misread the spec!

Dezy One thing that jumps out at me straight away about your settings is the bandwidth: 1600 is quite high. If you are optical fibre hard-wired, the maximum recommended is 1500. If copper wire 1000 and if wireless, regardless of what is downstream of the router, 500. Now that may not make much of a change but it will almost certainly reduce your packet-loss, which might reduce your perceived lag and building issues. The nVidia 9400GT GPU is no better than OK (I used to use one) and you don't use high graphics settings, but a draw distance reduction would help. 240m is a bit optimistic...try 160. Your OS, RAM and CPU are reasonable and ought not to cause issues. Also I try not to run other applications at the same time as SL, you really don't have enough CPU horsepower to do that.

Welcome back Maestro! Sorry to whinge, :smileyfrustrated: but this Grid Status Page issue seems to be getting worse rather than better! Today the Roll announcement did not appear until well after the rolls were due to have started, and reporting of last week's RC channel roll was completely missed. There are others here who are pointing out how awkward this is, the entry on the Google calendar is simply not enough. FWIW, the roll on Main Server seems to be fine, at least to me on all the sims I have been so far today. :smileyhappy: