Dear Lindens: Voice does TOO affect performance.

It places a higher load on system resources, reducing the machine's ability to process background tasks. One of the background tasks that has to be accomplished is at the network layer, assembling packets and their associated headers, broadcasting those packets, and listening for incoming packets. the computer is less able to do that as load on the resources increases. The resource shortage WILL affect the TCP/IP stack and its efficiency.

If enough computers are having resource problems, it will eventually affect the network they are connected to. What is not being understood here is that the routers on either side of this communication do not know and do no care whether they are receiving voice input or not. A packet is a packet, and it must be routed. If a machine is sending malformed packets to it because it does not have the resources to properly form them, the router will drop them.

The machine must then resend. And resend. It doesn't actually get EASIER to do that. While this is happening, SL for that computer, is not. All those bad packets clutter the network, and everyone's performance suffers, supercomputer or no.

I have some differences of opinion with you, Kascha, as to the exact mechanisms of failure, but the end result is the same. If users' PCs cannot handle what SL is asking of them, then there will be client-side CPU lockup, followed by network congestion and ultimately, failure of the application.

I wanted, however, to correct an erroneous impression that may be created by all this technobabble. People may be thinking that Kascha and others are saying that it would be impossible to add spatial voice to SL. Not so, imho, and I doubt that's what s/he's saying. I would be willing to bet that it is possible to roll out voice in such a way that both clients and servers are aware of the capabilities of the client hardware, and adjust the voice portion of the application accordingly. You could roughly profile the user's equipment, and use that to offer him/her only the level of functionality that their device could handle ... in some cases, no voice at all. However, that would be (as the nerds say) non-trivial. Note that SL has not succeeded in doing that for the graphical interface as yet, and certainly they've been trying. In fact, it would be extremely complex, and require careful observation of both network and application layering. The testing for it would be nightmarish, but feasible. It could be done. But not in the timeframe LL has allotted, given their staffing.

/me runs away before LL can take her new boots away for making a bet!

repost my little bit of opinion from another thread.

For those that don't know or realize, when you install the voice viewer there are 2 additional programs intstalled, SLVoice.exe and SLVoiceAgent.exe. Either one or both could very well eat up large chunks of your memory and cause problems client side.

Running on separate servers doesn't mean a whole hell of a lot, if the interface between those servers and the grid servers or the client is faulty.

The grid runs on a few thousand separate servers not one big server. Then you have the asset server, the log-in server and maybe others.

If the server side software is buggy (which obviously it is hence a lot of the problems even with non-voice) and if there are bugs are in the part of the application that is suppose to integrate the voice servers with the main grid servers, then the main grid can be impacted by that also. Which it obviously is also, hence some of the problems some people seem to be having with the voice client.

It's she, and I agree with everything you have said here. I'd really like to hear your take on those exact mechanisms of failure too. I'd be an idiot not to be willing to examine this thing from every angle and maybe find out something I did not think of