Feedburner

Nalates Urriah

Second Life: Performance Changing

As the Second Life™ system advances more of the content will be transferred to the viewer by HTTP protocol. This takes load from UDP and the region server-simulators and moves it to the Content Delivery Network (CDN).

Shadow Puppets!

We expect some degree of region performance improvement, especially in crowded regions with lots of avatars. But, there may be a cost for those on slow Internet connections. It is hard to estimate the impact on those with slow connections. But, there are things they can do if they see performance degrade.

In Preferences, there is the infamous Maximum Bandwidth setting. This setting only affects the UDP protocol, which used to be SL’s main delivery protocol. But, it doesn’t have error correction so lost packets are lost. Those were the days of texture corruption and cache clearing.

Users set Max Bandwidth to 80% of their max download speed or 1,500, whichever was smaller. This minimized the packet loss and eliminating packet lost was a big help to performance.

If you are losing packets, turn Maximum Bandwidth to a lower value. 500 is the default value. I’m not sure what a reasonable minimum setting would be. May be 100… try to keep it at least the default.

The idea here is to instruct the server to send to you at a slower rate. This setting affects the region server, telling it what you can handle. It has no direct effect viewer side.

Now as we push more stuff through the HTTP protocol we may see the HTTP traffic crowding out UDP traffic and increasing UDP packet loss. Such a problem is likely to exhibit self as jerky avatars and animated prims. UDP will primarily be used for chat and to update avatar movement, texture changes, and moving prim information

Live for moments you can’t put into words.

There is no HTTP throttle. But, there are a couple of settings that can reduce the HTTP traffic coming to your viewer. The viewer opens pipelines to the servers for parallel downloading. You can control the number of pipelines;

TextureFetchConcurrency: Maximum number of HTTP connections used for texture fetches. Zero is the default setting. At 0 the value is assigned by the server. Try values 7, 6, 5, 4, 3, 2, or 1.

Mesh2MaxConcurrentRequests: Number of connections to use for loading meshes. Default is 8. Try values 7, 6, 5, 4, 3, 2, or 1.

These changes will slow scene render performance but should reduce your network packet loss, which can kill scene render performance.

HttpPipelining should NOT be disabled. Disabling is a commonly recommended fix for texture loading issues. Oz Linden explains, “If you disable pipelining, you create a lot more TCP connection setup traffic; the connection setup packets are not congestion-controlled, but the packets within an existing connection are.”

Windows 10, and I think 7 & 8, have controls to determine the best incoming HTTP packet size. By default Windows 10 does not have congestion control enabled. So, a crowded pipeline is a crowded pipeline and Windows doesn’t care. (Reference) The TCP connection handles congestion in the hardware, the network cards, routers, and gateways.

If you are wondering how to test your connection to SL, use this information: Troubleshoot Your Second Life Connection. There are some Windows settings that can be tweaked to adapt Windows to your connection.

There are a couple of tweaks that can improve your network performance. By default, Windows reserves 80% of your connection for system tasks. You can change that and probably should if you have a fast computer and connection. See: How to Increase Internet Speed.

If you have a slow connection, this change may hurt more than help as it will increase the load on the pipeline. So, while it removes the limit on Windows it does nothing to improve the connection performance outside the computer. But, experiment and see if it works for you.

On a fast connection it is like removing a garden hose from a fire hydrant and connecting a fire hose. On a slow connection it is like hooking a fire hose to the kitchen faucet… not much benefit.

What do we need and where are the limits?

The minimum connection speed for using SL is cable or DSL. What does that mean in terms of speed?

In the footnotes the Lab states dialup is inadequate. Max dialup speed is 56Kbits or 0.056Mbits per second. OK, that is way too slow. It won’t even carry my UDP traffic much less the HTTP traffic.

Satellite speeds range from 10Mb to 25Mb. That is fast enough. But it is not speed that is the problem with satellite. It is latency or ping time. Internet satellites are 23,000 miles up. So, 23k from you to the satellite, 23k from it to the server then the packet has to make the return trip for total of 92,000 miles. That creates a minimum of 500± milliseconds of travel time, latency. The viewer starts to have trouble at anything >250ms and by 500 or 600 is dying.

So, we have some limits we know. Reading the forum, we find people getting by with 1Mb @ 250ms connections. I doubt it is fun, but the viewer will work. So, this is the lower end of what will work.

What is the best settings? NO ONE KNOWS! You will have to experiment and find yours. The troubleshooting article will point you at some of the tools used to measure your connection’s performance. The viewer can be used to watch for packet loss. Tweak your settings and use the viewer for a time and see what your average packet loss is. Adjust to your connection and system. Find what gives you the least packets lost.

Post navigation

2 thoughts on “Second Life: Performance Changing”

By the way, some packets sent over UDP are sent or received with a “reliable” or “repeated” flag, of which states that there must be a packet sent giving acknowledgement of receiving said packet, otherwise the client/region will retry.