You've been logged out of Second Life?

[JohnnyMM]

Hello guys,

 

Whenever i login to Second Life it kicks me out after 2 minutes and says "Darn. You've logged out of Second Life.This region may be experiencing trouble. Please check your connection to the internet." But my connection works fine and it keeps kicking me out when i'm in different sims too. What could cause this? And how could i solve the problem? (I'm using SL viewer)

 

 

[Imnotgoing Sideways]

SL is very intolerant of network faults.  If you're on wireless and/or DSL, there are likely issues with dropped and latent data throwing your connection with the server off. (._.)

While inworld, press Ctrl+Shift+1 to bring up the statistics window.  Check out the stats for Packet Loss and Ping Sim.  An optimal connection should have 0% packet loss and roughly 50ms or less ping times.  If packet loss exceeds 10% or Ping Sim goes beyond 200ms, you're bound to have issues. (>_<)

One method for softening the blow is to dial down your maximum bandwidth.  In Preferences >> Setup, there is a slider for it.  I reccomend 1400kbps for DSL, 2000kbps for cable over wireless, and 4000+ for cable over Ethernet. ()y

I strongly reccomend against DSL over wireless.  It's not impossible, but when supporting the worst connectivity issues, it's practically always that configuration.  (>_<)

 

 

[Callum Meriman]

---

Imnotgoing Sideways wrote:

 If packet loss exceeds 10% or Ping Sim goes beyond 200ms, you're bound to have issues. (>_<)

 

---

I would point out that this arbitary 200ms figure is likely a USA thoughtbubble and has no real grounding in fact. Those in Oceania who have lived on 250ms+ for a decade without issues, and those in Europe with 180ms+ in similar situations know that ping time doesn't have any real bearing on your connection quality.

[JohnnyMM]

Hello,

 

Thank you for your answers. I tried to dial down my bandwith and my packet loss is around 1% but it keeps kicking me out. So annoying. I have a 50 mbps connection but i dont know what causes this.

[ChinRey]

---

Callum Meriman wrote:

I would point out that this arbitary 200ms figure is likely a USA thoughtbubble and has no real grounding in fact.

---

Good point. I live in Norway and I've never ever seen ping time lower than 200 ms. Works perfectly fine unless you try to run a drag race against somebody living closer to San Francisco

 

---

JohnnyMM wrote:

and my packet loss is around 1% but it keeps kicking me out.

---

That may be the problem. 1% packet loss is annoying but not fatal but the figure you get from the viewer is often too low. I once had similar problems with you and with about the same packet loss according to the viewer. When I checked the line, it turned out one of the hubs my connection was routed through (in Sweden of course ) actually had 16% packet loss.

[JohnnyMM]

Ok. I tried all of those and i got 5 ms, I changed the routers channel. I even changed my wireless adaptor and nothing happened. It keeps kicking me out after 2 minutes unless i keep teleporting myself, this is the only way to extend my session time and it's tiring. Could it be because of ISP?

[WolfBaginski Bearsfoot]

A couple of things to note here.

1: There are several smartphone apps which show you what wi-fi networks are around you. The way the protocols work, you're actually using three channels, so the default chennel 6 will affect and be affected by channels 5. 6. and 7. Regulations in different countries vary about the outer limits pf the band. Some have 1 and 12 available, some don't.

2: Speedtest tries to automatically pick the test server with the bast ping time from where you are. This will give you an idea of how good your ISP is. But you should then find test servers near the Second Life server farm, which is in a suburb of Phoenix, Arizona. I have an internet ping time of around 160 - 180 ms into Phoenix. The Ping Time recorded by the viewer and shown in the Statistics window includes the delays in the server.

I've seen some very odd things said about ping time. It sometimes seems as though the server response time gets confused with the internet round trip time. Ping is a standard internet utility to measure the round trip time, and a little thing called the speed of light sets an unbreakable minimum. The signal in an optical fiber travels about 200,000 km/sec, and for a round trip time we can halve that to get 100km per ms. You Americans can call it 60 miles. There's also switching time at the internet nodes on the route.

If you're losing the connection, the number that really matters in the Packet Loss reported by the viewer. It's shown in the Statistics Window. It only covers the control signals passed between Viewer and Server. And it can be really messed up if you log in with a high draw distance and a high bandwidth setting. If packet loss is high, the viewer can decide it has lost the connection.

[LinuxGod4u]

First off you can manually select a server toward the west coast, USA via http://www.speedtest.net   I used to have to use satellite Internet (horrible) for SL even though I suffered major packet losses I never had issues of random disconnections. Random SL connection loss can be tricky, indeed to pinpoint. IF using a wireless router connection (not recommended) you are at the mercy of nearby routers, cb radios, any ham radio in the area, baby monitors, etc... In addition, it can be caused by ISP issues, or even *faulty hardware not to mention a Windows software conflict. It can be tedious & time consuming to resolve.

"I Love Simplicity"

[LinuxGod4u]

Trying to use a wireless router to connect to SL can be troublesome & not recommended. A closeby router, ham radio operator, baby monitor, cb radio,a smart phone close to your router etc can interfere with your wireless signal. Look up in your router's manual (always keep it) how to change WiFi "channel" usualy you can manually pick 1-8 & see if this helps. By default it is set to "auto" Try using http://www.speedtest.net   while manually selecting a server on the western area of the USA (Ca, or Az) see what your download & ping (lag) times are. I'd run at least six speed tests. Does your ping or download speeds fluctuate alot? IF so call your ISP have them perform a service call check out your modem, etc   IF not try going hardwired (Ethernet cable) see if you still have SL disconnect issues. IF this does not work you may have some software conflict issue. Always make sure you are using the correct software drivers too. Is your router going bad?? If nothing else works try disabling your antivirus just long enough to login to SL see if this resolves the issue. The worst case scenario have you upset some in SL recently? There are hackers in SL & although I am NOT one, nor do I condone hacking I do know it is possible for a hacker to gain control of your pc. This is why when I used to use Windows in SL I replaced the Windows firewall/antivirus with ZoneAlarm (free) since it alerts you to an attempted firewall breach/virus attack  & tracks the hacker's IP address, which LL & or your local authorities might find useful. IF all else fails assuming you have a Windows OS disk try a clean install of your operating system. Hope I have been of some help!

http://www.zonealarm.com/

 

"I Love Simplicity"

[Avron Vollmar]

I have been experiencing a very similar issue here, crashing out every few minutes with an error saying that Second Life has stopped working and needs to close down, it's extremely frustrating because I want to rp, and more or less impossible with constant crashing.  Getting 1% or so packet loss and the latency is all over the damn place, but the thing is that everything was working fine just yesterday.

[d0n4]

i am always on 200-300 ms on dsl but my packet loss are normally 1% or less  i am able to be logged a day straight with out loosing connection although every now and then i get a disconnect but is not often  you could call it .... "normal"

 

about wireless make sure you are on the less populated channel of your wifi in your area  i had tremendous latency problems in general when my wifi signal was overlapping neighbor wifi signals .... and it might be fine today but another day your neighbor might be downloading or something so there is trafic in the channel the best way to test if this is the problem would be to actually connect threw a cable see if the problem consists 

Edited March 17, 2017 by d0n4

[msmaybach]

Same here, the moment I joined a crowded nightclub. It just loaded the avatars and - BOOM. In other places it used to work but there were none or 2-3 at most 5-6 ppl there. The one time I found a possibly fun place and it breaks down...

[msmaybach]

The funny thing is that my laptop doesn't even have a slot for LAN connection so I'm stuck with wi-fi. I guess I'll have to steer away from crowded places...

[Love Zhaoying]

34 minutes ago, msmaybach said:

The funny thing is that my laptop doesn't even have a slot for LAN connection so I'm stuck with wi-fi. I guess I'll have to steer away from crowded places...

I bought a USB-to-Lan connector for one of my notebook PC's, worked like a charm. Plus, they are cheap and I didn't have to install any drivers.

[msmaybach]

I may try this out, thanks

 

[Rowan Amore]

1 hour ago, Love Zhaoying said:

I bought a USB-to-Lan connector for one of my notebook PC's, worked like a charm. Plus, they are cheap and I didn't have to install any drivers.

Yep, I had to get one of those for my old laptop when I gave it to my son.  Worked perfectly.

[Nalates Urriah]

I agree with most of the above... I'll add that packet loss and latency combine to additively worsen your connection. The greater the latency the less packet loss can be tolerated.

This is connection thing is a common problem for SL users. And many have the same reaction you had, my connection to the Internet is good. Well, yeah probably. But did you check your connection to the SL servers? Probably not. The Internet changes millisecond by millisecond. Several entities providing your connection are constantly load balancing and rerouting traffic. When an outage like AT&T's happens massive changes are made to try and cover the problem.

In 2011 I wrote Troubleshoot your #SL Connection. I updated it a couple of times. April 2023 is the last update. I suggest you work through it. You should get a  better idea of whether the problem is on your side, the ISP's, or the Lab's. Then you know who to call for help. Remember. Your ISP is likely to point fingers at everyone else... and deny ANY responsibility. The testing should help you convince them when it is their problem.

Also, your viewer and computer will give you different packet loss data. The viewer is working INSIDE the SL system. It includes all the network issues your computer will report AND... the viewer and SL server issues. So you can have a perfect network connection and an overloaded SL region server will still drop packets. This mean when testing your connection to SL you have more to consider and test for.

So, the easy testing requiring less technical knowledge is done in the viewer. Ctrl-Shift-1 opens the viewer stats panel. This gives you the data to know what is happening with your viewer and the SL backend/servers. The Basic, Simulator, and TIME sections are what you'll be interested in.

When all else is failing and when you and those helping have no clue, look in the viewer’s log files. The viewer has various log files you can read to get an idea of what has gone wrong. Look at the log immediately after you crash or exit the viewer. Logs are replaced the next time a viewer starts. You’ll find the logs in: Windows: C:\Users\[Win_login_ID]\AppData\Roaming\SecondLife\logs\ Mac: /Users/<username>/Library/Application Support/SecondLife/logs You will change folder and file names based on which viewer is used... But all viewers are similar. crashreport.log – This log is generated when the viewer crashes, the previous version of the file is overwritten. Rename this file if you plan to restart the viewer before examining the file. Otherwise, just read it with a text viewer (Notepad is good). debug_info.log – This file is internally formatted as an XML file. I never find it of much use. It is mostly the specs of your machine. SecondLife.log – This is the main log file. I find it the most useful. Start from the end of the file and work toward the beginning. Search for ‘WARNING’ and ‘ERROR’. With any luck, the messages there will give you an idea of the problem. Recent changes have added a section heading to parts of the file that can identify the general nature of the problem. There are lots of performance stats included.  At the end of a session with no crashes the end of the log file will contain secession stats;  Run Time, Average Packet Size, Dropped Packets, Resent Packets, etc. The file is replaced and recreated for each viewer secession. SecondLife.error_marker – I don’t know what information is inside. I don’t have a copy to examine as I write this.  The presence of the file indicates where, when, and what error happened. I think this is a disaster backup file for crash reporting in which information about the crash is retained in the event the crash handlers are destroyed before they can create the other more complete crash files. SecondLife.start_marker – There is no information inside. The presence of the file indicates how far into the start process the viewer has gotten. Whether the file exists or not is the pertinent information. SecondLifeCrashReport.log – This is another file internally formatted to XML.  It is created when the viewer crashes. I think this is the new version of the crash log. It is mostly text. stats.log – This is a short file containing network statistics. Similar information is in other log files. It is an easy-to-read set of stats that show how many packets were dropped and resent in a secession. I find the SecondLife.log is the most useful file for tuning and troubleshooting the viewer. It is verbose and reasonably easy to understand. There is a Debug Setting that allows you to increase or decrease the level of reporting. Most of these files are erased when the viewer starts. If you plan to send the files in with a trouble ticket or bug report, place copies in another folder immediately after a crash and before starting the viewer again. Marker files are temporary and may or may not exist at any given time. Entries in the files associated with errors and warnings are labeled as such. That makes them easy to find by searching. Search and read through them starting at the end of the file and working backward. Warning entries are common and do NOT necessarily mean there is a problem. Some warnings are a part of normal operation. Some errors are trivial and do not indicate a ‘noticeable’ problem in the viewer’s operation.