loosing connection

hi everybody!
very often happens to loose connection. the most of time its on TP, but sometimes i experienced the same problem also while acting on an object, or opening the map, or the inventory. is it a known bug?
the connection works again after 30 secs (1 min at max) itself. so, i see my modem resetting itself (by looking at blincking leds).
i have the same problem on different releases, 1.20.15 official, 1.21.xxx RC, and 1.21.xxx Cool SL.
is it time to change my ethernet router/modem or is it a sl bug?

PS: my router/modem is a modem but with ethernet/usb connection. could a real router give me a slower speed than an ethernet modem in SL? or is there no differences while connecting with the 1st or the 2nd one?

tyvm in advance, peter.

Sounds like an ISP overload problem, or modem overheat, not generally SL. You can run some tests to load the modem and see if it does the same thing

About using a router, no negative affects happen using a router. Your internet speed is, maximum 10mb/sec, on a really high end home system. Most routers today run 100mb/sec data transfer through the CAT5E cables. Some are also in the 1024mb/sec crowd, and are called Gigabit LAN. 10/100 operates from 10mb/sec-100mb/sec and is most common.

Run a simple test on your modem, stress it either with a massive file download at full speed for a few hours, or find a modem testing program somewhere! Just download Debian DVDs, all at once, and im sure that will stress it enough to do a stress test.

i dont think its an ISP issue, i had the same problem with the official release and the RC, but since i installed the Cool viewer i have a stable connection again.

greets,
Volkmar

First: Specs.

Ubuntu 8/04, Acer 5920 w/ Nvidia 8600GT M, 2 Gigs RAM, Intel Dual Core 2 GHz.
Connected via WLAN (internal) by Alcatel Speedtouch 585, 3 mbit DSL.

When running the 1.20 AND the 1.21 RC, everything runs fine. For somewhere between 3 to 15 minutes. Then the client starts to freeze occassionately, then more and more and comes to a halt, including the system, if I am not fast enough to shut it down. After closing it down, even when the freezes start to occur, I cannot access websites, and othe rprograms stop their connections as well, like Skype or other IMs, mail programs and other stuff currently running.

Installing the cool viewer, latest versions, lets SL not run at all anymore. V1.19 runs Coolviewer V3, NOT LATER, and 1.20 or 1.21 RC same with all versions of collviewer. SL starts then up, the black start screen appears, the window disappears, as well as the taskbar icon, but systems monitor shows the process still running, so I think it is decoupled somehow from the X Windows.

So I am stuck with SL 1.19.0.4 W/ CoolViewer Rel. 3. *sigh*

Any thoughts? Thanks, Xe

I have the same thing - especially after a TP, but not always, I lose my connection and need to restart SL.

I have had this for the past year or so - that is why I was so determined to get the little status bars at the top of SL back, that is an easy way to see that SL is not connected any more.

This has been reported so often and for so long, I assume it is a feature of SL, not a bug, so I don'tt bring it up any more.

However, since it irritates me madly, I also stopped coming into SL.

That is how it sometimes works out when an unwanted feature irritates.

Sounds like an overheating DSL modem... try setting it on the floor or someplace where it gets more ventilation, or both. Failing that, time for a new one.



Ethernet or USB, not both at the same time. Should be no difference assuming your router is properly configured (ie, you haven't gone out of your way to break things), though USB will be the slower option between the two media.

Maybe someone should tell LL about the Cool Viewer? Maybe they can use its network interface to get SL stable

Your SL client can't possibly affect your DSL modem's stability. There is more at play here than is being articulated to be sure.

I don't think in the least that this is a dsl modem problem, since 4 other people are using the same dsl modem and are not losing connections to their online games, especially not when I TP in SL

I am however losing the connection to SL when I TP.

The problem is the connection to SL is not stable, and instead of resending or requesting a resend, SL decides to just wait, and wait and wait... eventually I notice that nothing is reacting... and restart SL. It is then fine - unless I decide to TP, of course.

Maybe if I cooled my DSL Modem it would not know that I was TPing, and forget to drop the line between only my SL and Linden Labs? Or maybe decide that the others using the dsl modem should be dropped instead of me being disconnected from SL?

I must really speak sternly to my DSL modem - why does it hate SL?

I guess it hates Linden Labs, though - from what I have read, the Cool Viewer is not generally hated by dsl modems.

But we don't know if theirs is exposed to as much external heat as yours.



Which I strongly suspect is coincidental, I suspect if you changed servers on anything else that streams like SL does, you'll have the same problem, as you are when you're teleporting.

The rest of that statement is identical to problems I would see in-world shortly before my DSL modem reset before I moved it to a cooler spot. I probably teleport around less than you do.



I'm sorry, but if you want to solve this problem for yourself, you really do need to apply a little bit of basic electrical knowledge and take it seriously: Overheating electronics can fail and/or catch fire.

There's zero interface between any SL client and your DSL modem: The correlation you are seeing is not the cause. Feel free to ask around among the client developers and they'll tell you the same thing.

a) It may not have been clear from my post, but they are not connected to the same TYPE of modem, this one physical modem is the connection for all the other users too. So they would have the exact same overheating problems / modem glitches as I have, since it is the exact same modem.

b) Suspecting is not knowing. It is guessing, and needs to be verified.

c) There is ONLY one DSL Modem for all the users on our computers. Only SL has a disconnect problem, and that only really after I TP. QED - the modem is overheating? I am glad you found an overheating DSL Modem solved your problems, but I do not think this is a "one size fits all" problem.

d) What is overheating? The modem we have is in a very cool location, far from the heaters we use to keep the room warmed up, and has lots of air circulating around it.

e) What has the DSL Modem got to do with it? This is an old SL problem which has resurfaced. The OLD fix was setting bandwidth to around 300 kbps, but that does nothing now (it only rarely worked before). If there is zero interface between the DSL Modem and the client, how can the modem be the cause? In linux you can watch the packets being sent, and the disconnect coming, in the protocol files. No sign of retries or resend... Too much overhead, I guess

I really appreciate your involvement, but I can assure you, it is NOT a Hot Modem in my case. It could be a junk modem, but there I have no choice - it is supplied by my Tcom company.

It would have been nice if you could have helped though, your energy would have come in handy.

well, my DLS modem is def not overheated and i guess we all dont use only one special type of modem (as i know there are a lot of manufactorers)




and this statement you can forget, maybe you should take a better look to your viewer, look at your preferences and you will see some points are interacting DIRECT with your modem/connection, for example the minimum bandwidth you give to SL.

My question: if its NOT SL, why all other connections (videoconference, sound streaming, backup of the internet *grins*) are running stable without any cut ???

Greets,
Volkmar

It is probably that SL does not build a session from the SL Client to LL's servers, but uses a sort of "oops!" system, where if there is too much lost or it takes too long, it just drops you from the data transfer server side.

A pity, because if that is true it is not likely to ever get fixed - the philosophy and protocol would have to be redone.

The emphasis in SL development currently seems to be on the Visibles, not the Fundamentals. After all, you should have something to show for your efforts, and reliability does not "show" - it is just "missing problems".

I am SOOOO glad to see I'm not the only one with this issue! I've been having exactly this sort of thing with all iterations of v1.20.xx and with the v1.21.xx RC viewers. v1.19.1.4 runs perfectly. Mine is even more frustrating because, when the viewer freezes up, my CPU usage pegs out, and my wireless card gets knocked offline. I used to be able to do ifdown/ifup to restore my wireless connection (after finally managing to shut down the viewer), but with Ubuntu Hardy, these commands don't exist anymore - so I end up having to reboot to restore connection.

This makes viewer versions 1.20.xx and 1.21.xx complete show-stoppers for me. There is no real pattern, rhyme, or reason for these freeze-ups. Like you, the viewer will be completely fine for a while, and something as simple as slewing the camera will freeze everything up. As soon as I lose my wireless card, my CPU usage drops and I can get control of my computer again, though it still freezes in spurts until I kill the viewer.

This bug really needs to be hunted down and squished before 1.19.1.4 becomes no longer supported. I will dump SL before I resign myself to using Windows.

As far as I know, some of these missing commands can be found by asking for help on the ubuntu forum, try that. Some have new names with new binaries that have new functionality. Try the Ubuntu forums, I have found this very helpful - and I use SuSE!

Don't think of Windows as a refuge on this issue, I use the windows viewer and it has the same issues. At least in linux we can use the cool viewer, which seems to have less of a problem with this.

Hi there,

I just use the networkmanager usually shipped with each Ubuntu flavor... that one you connect to your WLAN with. It has usually its icon in the taskbar, just re-select your WLAN network. At least that spares you the reboot procedure.
What it does NOT spare you is the issue that other programs running in the background, like downloads lets them loose their network connection as well, and some programs take that quite bad from you.

Putting CoolViewer over 1.20. made those network freezes a bit less, in amount, but the effect stays the same.

Changing from Ubuntu 32bit to Ubuntu 64bit (caused by RAM upgrade to 4 Gig) did NOT solve the problem, by the way.

In fact, as far as I can determine ist that above reports seem to be true. When SL hickups, it does NOT to try to reestablish the connection, it just locks up, killing the network by extensive CPU usage.

I also spotted a JIRA entry, but it was set to "More information needed". A broken down network connection after a SL lockup should be enough information in my opinion, together with the machine specs, SL version number, patches applied and when it occcurs (here: without pattern).



At the middle of october, I switch from DSL / Wlan to Cable Internet w/ Ethernet (got a bit fed up on WLAN lately). But as far as I saw, people w/ ethernet connection have the same issues, SL killing itself completely, but not loosing the physical connection so far. The network there just blocks (!).



i also found Windows users being affected as well, it is not a Linux issue, it is a COMMON networking problem, as it seems. I teamed up a bit with some other SL users, on Mac and Windows, and try to find a pattern, indeed. Even the Mac users report similar problems, which surprises them to the bone. *smirks*

And my Aspire came with Vista. NO WAY i put THAT on my harddisk, rather I would give SL a loooong break until I see a working viewer again. Pity for my pals.

Cheers, Xe

I agree: this needs to be fixed.

If LL needs more information, and it is a general issue (and a real show stopper, in my opinion), then LL should organise a team with affected users to gather information ACTIVELY, and not sit on a "need more information" comment in the Jira.

Perhaps a debug version or setting of SL that can capture the events, and these can be either included in the normal crash report - it IS a crash of functionality!!! - or, a bad second best, these can be sent to some address at LL, NOT the Jira (only beta testers know how those things work, not normal users).

When this first started happening regularly, about 2 years ago, I was amazed that this did not lead to an automatic crash report on restart. I guess someone thinks, if the process is still running (even though it is effectively dead), it is not a crash?

Well, it IS a crash. If they have ever been involved in client server operations, they would know that this is a very serious crash, and much more dangerous than a process disappearing, because it gives all the appearance of a fully functional system, and the system is really dead.

Hi again,

I am not an official tester for LL, just an ordinary SL user that gets a bit driven insane if your swordfight is ended by SL killing the connection rather than by skill...

I will install wireshark monday, and then let it log until such a disconnect occurs. SOme megabytes of log should enough information then... just kidding. I think the relevant parts before, during and after the crash should then be information enough, I hope.

Greets, Xe

I do hope this problem is found. Someone else in another thread observed that this does not affect everyone, which makes this problem all the more frustrating.

Part of the solution may be in finding out what is different between 1.19.1.4 and 1.2x.xx - ie. what in the newer versions could be responsible for occasionally spiking CPU usage to such a point that there isn't enough CPU time left to maintain the wireless connection.

Additionally, I'll post my lspci information, since it seems a specific hardware combination may be contributing to the problem:

On an HP Pavilion dv9730us, configured with 4GB DDR2 memory, an Intel T5550 Core 2 Duo processor, running Ubuntu Hardy 32-bit - gstreamer-010, Pulseaudio, and WICD as the network manager. Wireless connection is on an 802.11n wlan using WPA/TKIP encryption (problem also occurs when connected to 802.11g network). lspci results:

00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)
00:01.0 PCI bridge: Intel Corporation Mobile PM965/GM965/GL960 PCI Express Root Port (rev 0c)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)
00:1c.5 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 6 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 03)
01:00.0 VGA compatible controller: nVidia Corporation GeForce 8600M GS (rev a1)
02:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN Network Connection (rev 61)
06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
07:09.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 05)
07:09.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 22)
07:09.2 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev 12)
07:09.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 12)
07:09.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev ff)

If any more information is needed, please let me know.

i noticed some similarities between your configuration and mine. Here is my LSPCI output (sorry for the quote):

00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 03)
00:01.0 PCI bridge: Intel Corporation Mobile PM965/GM965/GL960 PCI Express Root Port (rev 03)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)
00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 (rev 03)
00:1c.5 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 6 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 03)
01:00.0 VGA compatible controller: nVidia Corporation GeForce 8600M GT (rev a1)
04:00.0 Memory controller: Intel Corporation Turbo Memory Controller (rev 01)
06:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN Network Connection (rev 61)
08:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)
0a:09.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 05)
0a:09.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 22)
0a:09.2 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev 12)
0a:09.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 12)
0a:09.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev ff)

The first candidate for misbehaving hardware (TM) would be the graphics card. I have a NVIDIA 8600M GT, you a GS, but same brand. Usually, those have the same drivers (here: 173.14.12) The Ubuntu shipped Version 169.12 is known to be faulty, so replace it (try envyng, very smooth).

Second: I use ESD, Pulseaudio gives you a major headache when you use Skype regularily.

Third: Chipset. We have the same make ( Intel Corporation 82801H (ICH8 Family)) as well as the same chipset, just a different revision. I use an Acer Aspire 5920G.

What we can eliminate, is the difference between 2GB and 4GB RAM (upgraded, same problem), as well as the 32bit version and 64bit version (upgraded as well, because of Ram upgrade).

Will look further into it...

Cheers, Xe

i've ran tests on this and on an another modem (my ISP granted the exchange) and i experienced different matters: running SL, i loose connection after 15 mins, always on last TP (stuck), and the only way to resolve is logging out sl (otherwise it will do itself), running “sudo poff dsl provider” and “sudo pon dsl provider”. Doing that, everything back to normal, since the next 15 mins; if not i can't access to internet.
So, maybe it all depends from ISP problems?





how can i have “little status bars at the top of SL”?






tyvm for your suggestions!!!



All that i can say, is that now the matter for me is worse than before, becouse before my connection worked again after 15/30 secs itself, and without logging out sl, and now i must run "poff and pon dsl provider" to have it work again.
PS: from kubuntu edgy eft 6.10, the only thing to do to be connected to internet was "pppoeconfig" only after a fresh distro installation and only for the 1st time. doing that it is auto loaded (i want it like so) on booting. only last time i had to run "poff" and "pon" commands.

There is an option on the configuration page, something like "Show Search bar...": I cannot start SL at work , if I get onto the computer at home I will tell you exactly.

tyvm!!! i'm waiting for your reply

just in this moment i experienced to loose connection only by surfing by the web, after 30 mins. now my question: could it be a linux bug, or only a isp problem?
i had to run "poff dsl-provider" and pon dsl-provider" to have connection back, and instantly.
the same happens running knetwork manager or wicd, and running kde3 or kde4.

ps: i'll try to run windows to look if have same matters.

Here it is:

Under Preferences, General, near the bottom: "Show search panel in overlay bar".

If you uncheck that, you get the network histograms, for want of a better word, one with download rate, the other with bad packets.

They go very high when you log in, or tp.

When you log in, they stay high a while.

Often when you TP, they disappear. That is the "oops" moment.

And to the previous poster: it is not only a Linux problem (I have it under Windows, too), it may be an ISP problem, an overloaded TCP stack, a browser or indeed a modem problem that sets it off. The painful part is, that SL does not connect again, have a reconnect option, or in fact, that SL disconnects at all Browsers also lose connection, as do other applications like my "Internet Drive"; but when I need more data, they reconnect - the client rebuilds the connection to the server.

SL does not, and PARTICULARLY in SL, that really kills the experience.