
Peering Inside: Linden lags, a failure to communicate
Filed under: Culture, Opinion, Second Life, Virtual worlds, Peering Inside
One of the most common complaints from Second Life users is that Linden Lab and their support staff either ignore or are dismissive of ... well, of one of the most common complaints from Second Life users: Performance and lag (commonly seen as the same thing).
Like the recent problem with the bug that ate up simulator performance like candy. When it was reported, the response to the user reports was chilly, bordering on hostile. Why is that?
Unfortunately, because more than 999 reports out of a thousand of performance or lag problems are either wrong, or are outside of Linden Lab's control. Face it, in the same position you'd get rather tired of things pretty quickly too.
Firstly, most people don't know what causes lag, how to measure it, or how to locate it. In my experience it's almost never where people think it is, and almost never caused by what people think it is responsible.
You don't have to be an über geek (sorry, to our German readers for whom that should probably read obergeek. English-speaking gamers do funny things with your language) to get it right. What it takes is basic knowledge (that isn't all that hard to acquire - we've covered this topic previously for simulators and other causes) and tools, but even then it's possible to make embarrassing mistakes.
At the Intel ASR launch last week, the Intel simulator went into a burst of poor physics behavior, causing a general slowdown for everyone in the sim. An Intel representative at the event quipped that if their new ASR routers had been in use, then the lag problem would not have occurred. Since the whole issue was not network related, and was contained within a single server, the presence or absence of Intel ASR routers would have counted for exactly zero.
See? You can command a decent salary at Intel, and still get the basics wrong.
At another event everyone's complaining about the simulator lagging. Which it wasn't (the simulator was just fine and nowhere near capacity). Everyone's shouting advice at everyone else to do things that they falsely believe will reduce simulator lag. Several people started sending IMs to random Lindens in the hope that someone will come and fix the simulator that actually doesn't need fixing.
That alone, must be awesomely frustrating.
Some users adjust their preferences upwards to the point that the viewer or their PC can only barely handle their requested settings. Others pack their connection with P2P file-sharing and then complain about packet-loss and delays. All the complaints go back to Linden Lab.
Of course, Linden Lab's simulators do get overloaded, as do their other databases and networks. Yesterday was a prime example of that, where there were assorted difficulties and failures grid-wide from late Saturday night through to mid-afternoon Sunday.
The question is, how do you separate out the actual problems from the imagined ones, when the vast majority of problem reports are wrong, or are things that are beyond your control and cannot be actioned?
Given all that it's not hard to see how Linden Lab's support people can seem uncaring about performance problems. Most of the reports are false or misleading, and responding to the scene of even a small fraction of the reports would leave little or no time for them to provide any other kind of support.
Unfortunately, it also generally leaves the handful of genuine reports out in the cold.






Reader Comments (Page 1 of 1)
3-10-2008 @ 11:17AM
Cyn said...
Every so often I mention the new lag meter to people, and most of them have not heard about it. It's one of the most useful tools I've seen come out of LL recently, and few people use it. I bet that's very frustrating to them as well.
Reply
3-10-2008 @ 2:42PM
Eloise Pasteur said...
If you live in the UK the lag meter almost always shows network lag. I'm guessing it works from ping times (at least in part) and thanks to more switches and longer cables, the ping times are always longer. I can accept that, and live with it, and don't expect the same performance as if I lived next to the co-lo, but it does make me wonder how useful the tool is if, just because I live in the UK I alway lag.
Given I'm on a 10MB down stream, and I can and go get the lag meter continuously in the orange with nothing else running and sitting in a box at 500m with nothing else around and minimum settings I don't believe there's much I can do - but I do believe their expectations might need adjusting.
That said, Tateru's article is a nice explanation of why - the question then becomes should LL change their processes? If there was an semi-automated reply that said "Thank you for your report, without x, y, z details we can't tell what is going on, if your problem persists please send them" then LL would get better "lag" reporting (hopefully) and then the separating of the wheat from the chaff might be simple enough to let LL respond. Result? Happier customers, probably happier employees, hopefully faster SL.
3-10-2008 @ 4:05PM
Cyn said...
I remember when I was still getting used to SL, I'd dutifully file the crash reports the system asked me to. When I put in an extra gig of RAM, I didn't crash any more. My conclusion is that the lag and crashes were all the fault of my computer, but there was no way for me to know that at the time, and so LL got many reports from me that indicated crashes not their fault -- but their system had asked for the crash reports. They need some kind of sanity filter at the beginning of the process to reduce frustration.
The lag meter could turn into that kind of sanity filter.
For example, what if Avatar Smith wants to file a lag or crash report, and the system asks him to first check the lag meter? If the meter has client or network lag, but no system lag, then he is told that LL cannot help him, as he needs to upgrade his computer or speak with his ISP. That would increase the useful data on real problems arriving at LL.
Reply
3-10-2008 @ 8:40PM
Nock Forager said...
Cyn, with your report, LL at least could know how many peoples crashed and feeling problematic with low PC spec. It will encourage them to reduce laggy part of client software, and yes thinking about needs for light weight client. I think sending crash report is not waste of time.
BTW, I recently know this System performance test page. ( http://secondlife.com/support/systest.php ). It's nice tool helping non-geek users determine and tell others his/her problem. Hope this tool going more advance and analyze other, such as network, system lag things too.
Reply