Peering Inside: Linden lags, a failure to communicate
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.
