Yes, your home router could indeed be letting your Second Life experience down, and a couple quite common series of routers are among the most culpable.
I’ll start by pointing out that the IEEE 802.11 networking standards aren’t the easiest set of networking protocols to implement correctly in device firmware. It’s all too easy to get them almost right, resulting in wireless access points and routers that work just fine for some kinds of workloads and that fall down spectacularly for others. As a bonus, RFC-2663 IPv4 Network Address Translation is also a commonly poorly-implemented feature in many network devices.
In my experiences from 2000 to 2005, the vast majority of wireless access-points/routers of that period – while just fine for Aunt Tilley and her Facebook habit – turned out to be duds (ranging from extraordinary failure to far more subtle symptoms) once you hooked up a power-user or a small three or four person office. They might choke and die, they might toss stations off at random, they might just run some connections very slowly, or some might unpredictably stall, leaving you wondering.
Finding good hardware during that period was a chore, and it hasn’t gotten that much better since, in my opinion. Often the best you can hope for is “just good enough” (if you’re lucky) unless you use something like a dedicated Linux system as a firewall and router.
Even such networking giants as Cisco Systems has gotten them wrong on occasion. Few (if any) manufacturers seem to be entirely exempt from glitches in these particular standards implementations.
All that said, Linden Lab has recently been performing somewhat extensive testing of consumer routers as a part of Project Shining, and come up with two common series that are already problematic with Second Life.
The problem units identified by Linden Lab as problems for Second Life users are the Belkin G series of routers, and the LinkSys WRT series (that’s a picture of mine up at the top, by the way – yes, I’m one of those affected, and don’t think I haven’t noticed already) among others. The problem extends to both the wired and wireless side – that is it isn’t just deficiencies in the wireless protocol implementation, but in the Network Address Translation portions of the router, through which all connections must pass going to (or coming from) the rest off the world.
Peter Gray, Linden Lab’s spokesperson told me, “The Viewer can be hard on some home routers – a single Viewer instance can look like dozens of browser sessions (e.g. a small office) in certain aspects all by itself. In the worst cases, it can sometimes crash home routers or cause them to drop packets, which the user experiences as a brief network interruption while the router reboots or poor network performance.
There is nothing about Second Life that is intrinsically incompatible with any router, but we are working to make our network usage less hard on all routers; that’s a central element of the HTTP Library component of the Project Shining that we announced in our recent Tools & Technology post.”
In the meantime, I’m going to set up a new router. I’ve already been aware that the current one isn’t handling things – notably Second Life – as well as it could (and we don’t even use the wireless side of it for the most part). Rather than messing with consumer network appliances, I’m going to grab an old PC and a Linux install disk and throw my own router together. It’s really what I should have been doing already.
For tinkeres, you might check out the default MTU settings in both your router & your TCP/IP configuration, esp in older Linksys WRT routers (I’d personally never buy a Belkin router).
Many times you’ll see the value MTU 1500 – this can leave some configs choking; lowering it to 1492 (easy to remember- Columbus & all that) can smooth out collisions. A useful program for tinkerers is TCPOptimizer – it will scope out many Windows comm parameters. It has a pretty thorough HELP file with a lot of information to help you understand TCP connections. It also has a Backup Settings function that is invaluable when trying configs.
Messing with TCP/IP parameters can be subtle and varied, so I’d (mildly) caution anyone not familiar with such things to be cautious, read the HELP files, maybe do some research into what the Values are and BACK UP the config before you adjust things. But the right settings can provide a smooth, optimized communication throughput on many machines.
I’ve always had busy sims crash my router. Nothing else ever did for the longest time so I blamed Second Life, but occasionally even the revamp of Netflix’s catalog page crashes it. So I’ve figured since then it was my router.
Never thought it had to do with the brand/model of my router though. My Belkin Wireless G is 3 years old or more now but it cost me almost 100 USD when I bought it.
Good to know my router is just crappy and I can improve SL performance by getting another one. Anyone have a wireless router they can suggest that also has at least 2 wired ethernet ports?
I went with an old Linux machine too. I guess when searching for a good router you could google for one that can handle bittorrent well, since the problem is similar – many simultaneous connections.
I use an Asus RT-N16 loaded with DD-WRT. The hardware handles can handle a large load, and ddwrt gives you amazing power in a simple interface.
I have been using a linksys wrt54g for years with dd-wrt installed and have never had any problems. There are several people using SL at the same time on it as well as file servers and print server. I highly recommend the DD-WRT software, go to their website and see if your router can be flashed.
Routers are a pain in the ass, internet is a pain in the ass. So many variables make up a good connection, Location, make of router, wireless, shape of house, OS settings, router settings, ISP settings, Software you are using, the amount of people using same exchange….. I just replaced my router with a new Netgear router as my old one died and i had to communicate with my iSP to configure the connection at their end to talk more clearly with my new router. I never considered that different routers talk differently to iSPs. As for second life, I’m always shocked at how much data it transfers, more than watching online video in most cases. It would be interesting to see if the Labs project shining will reduce the amount of data the viewer downloads.
[...] Your router could be screwing up your connection to Second Life – from Dwell on It by Tateru Nino [...]
The Linksys WRT are also notorious spam bots, since few people change the default password and the Linux kernel is easily reflashed by viruses. It makes it impossible for anti virus programs to spot the problem. I turned off my Fios router and jacked in a Netgear. SL ran much smoother, no more router reboots were needed, but still had some speed issues and dropped packets. In my case, Ialso discovered that the WEP protocol was at fault. Switching to WPA seems to speed SL up a lot. WEP, in addition to being insecure, has performance issues.
Counterintuitively, if your CPU is very busy, lowering your bandwidth in the SL ctrl P menu will help. The SL FPS figure in the ctrl shift F1 menu includes the processing of network packets, and not having enough CPU, perhaps due to a laptop video card, can cause your CPU to be flooded with packets it cannot keep up with. Lower the network bandwidth to just above the graph value or even lower, until yor CPU has some spare time. Wait a few minutes, and check it a few times. I ended up boosting a (high performance) laptop with only 3-5 FPS to 10-15 FPs by dropping to 300k bps network setting. This was in spite of having a 40 mps connection, due to an old video driver for Vista. Reformatting with Win7 64 bits let me get new GPU drivers and now the same laptop FPs can run into the 60s with network at max.
I noticed the CPU-load problem a while back, and for me it mostly vanished when I switched from Windows XP to Windows 7, using the same hardware. I’m sure there are other reasons, but remember how old WinXP is.
My ADSL modem-router is a Voyager-2110, old but reliable. It was originally sold by BT in the early days of ADSL in the UK. I have noticed occasional glitches with wi-fi and recent hardware such as my Android tablet. Wi-fi will always have problems as different networks, and other noise sources, compete for limited bandwidth. And the way that network capacity has been sold, I know I cannot depend on adequate bandwidth at some times of day.
Second Life has to change how it uses bandwidth. Some of the Project Shining elements (The cache operation: did they never notice?) will pay off. But I do sometimes wonder if the Lindens have ever understood the Internet. HTTP textures, for instance: how often were we told to try turning that off?
I can see what they’re getting at, the number of connections. There’s ways of putting limits on that, in Preferences, at least for textures in Firestorm. But is it so obscure a problem?
I confess, I sometimes wonder just what sort of Internet they design for.
Just getting on the mailing list. Interesting topic
I’ve had a WRT54G for eons, and I only experienced the problems LL describes when using the official firmware. I’ve been using the Tomato firmware, on it for most of it’s life, and it has been one heck of a fine little box. The Tomato firmware is one I’d easily recommend to others. DD-WRT is also a fine (and highly extensible) firmware, but Tomato is a better fit for people who just wanna install and have it just work. Particularly if you’re new to open firmware, and don’t want to wrestle with things like iptables, loopback issues, etc.
I am now looking into a new router… having just B/G Wifi is starting to feel a bit creaky, and I want to be certain I won’t have any problems on the day that my ISP finally enables IPv6. Even if I can wrangle DD-WRT into providing IPv6 support on the WRT54G, I’m not at all confident it has the memory for things like the larger routing tables, etc. The Asus RT-N16 is really quite tempting, but so is the Netgear WNDR3700. I’m leaning toward the Netgear right now.
IPv6 is going to do interesting things to problems such as this, and it worries me that my ISP, last year, admitted that it didn’t have any plans for the transition, not even apparently being able to say that hardware they provided to customers was compatible or not.
Reflashing the firmware is generally not for the faint of heart. Mine actually can’t be – its firmware is in ROM.
If you’re going to throw your own router together, can you document the process ?
1. Find your router in dd-wrt database http://www.dd-wrt.com/site/support/router-database
2. Read ‘Flashing Instructions’ specific to your router.
That doesn’t refer to what Tat said she was going to do, and unfortunately my router isn’t listed in the dd-wrt database.
I almost read this article title as “Second Life could be screwing up your routers connection to Second Life.”.
But then I blinked.
Some fairly recent research by Bell Labs programmer Jim Gettys has shown that devices are buffering packets to the detriment of the network. He is calling this “bufferbloat” and you can find information at http://www.bufferbloat.net/
The problem seems to be that the buffering in a lot of devices doesn’t empty very well. The buffer stays nearly full, and it can take several seconds for a packet to work through the queue.
1: These buffer problems don’t necessarily show in ping times. Different protocols, for one thing.
2: A buffer is there to deal with unexpected delays and out-of-order packets. A nearly-full buffer can’t do that job well.
3: Switching to HTTP textures has likely meant that SL has become entangled with the problem.
It does rather make sense of the advice to try switching off HTTP textures.
It could also mean that regular reboots of the router would make a difference. But how long before the buffers are full again.
Heh, interesting! I’ve been using Linksys WRTs forever, and haven’t had significant problems that seemed to have anything to do with the router (i.e. they’ve always gone away when I change point-versions of the browser, or lowered MTU, or whatever). Haven’t been using any official LL viewers much in recent years either, though; are they somehow the most vulnerable?
I’ve been helping one of LL’s Core Platform devs (Monty) on these issues off and on for the past year and a half.
This issue has existed since viewer 2.0 and has only gotten worse as more things have been moved to CAPs. One of the current main problems is that the viewer is essentially has to spam new connections for every request instead of being able to reuse the same connection for the entire query. Nearly all of the problems are rooted in many bad decisions made these services were originally created. Simply correcting the configurations would cause ever larger problems.
So whats happening is that when you connect to a region, the viewer is opening and closing in very rapid succession 100′s of connections a second. Even small business routing hardware has difficulties handling this. You basically need a router with a lot of ram, which one revision of the Linsys WRT54g (namely v5) does not have while earlier versions and the “L” revisions would be fine.
Another unrelated problem is that Viewer 3 traffic can appear to be masked bittorrent traffic by ISP bandwidth management systems. Lots of connections plus http transport of compressed data over non standard ports looks fishy to say the least.
It makes you wonder if HTTP is a protocol that should never have been used for SL, given the way it works. Unless I’ve totally misunderstood, HTTP is a separate connection for every item: every element of every web page is a new connection.
It’s a technology that is there, with libraries to use it. You can see why it gets used as a layer between the software and the TCP. It needs some pretty smart people to produce an alternative that would better suit SL.
But was there really no choice?
HTTP is well suited for this, the problem is that LL make some really poor decisions when originally setting it up and now they can’t easily fix it without causing a flag day.
One of the main issues is that HTTP keep-alive is disabled server side. The viewer actually attempts to use it, but the HTTP servers won’t allow persistent connections. Technically this could be flipped on, but doing so would cause more problems as now every viewer is maintaining many active sockets at once because its been made to workaround this. (More info on keep-alive: http://en.wikipedia.org/wiki/HTTP_persistent_connection)
There are more issues, but this one is a biggy and easier to explain. The solutions are not straightforward and LL has been working on it for over a year (that I know of).
Thanks. That explained what I heard. I must be more out of date than I thought.
From what I’ve been able to gather, many of these bad configs were make over 5 years ago. And now that we are using more things over CAPs (HTTP), we have started to see the problems emerging.