This message is looking at it from a slightly different point of view, however these are some observations about what happens with the client and OpenSimulator.
Firstly, the client will adjust the actual throttle settings based on packet statistics that it internally keeps. This means that the slider is a 'guideline' and the client will do it's own adjustment of that as the network conditions change. With debug on, one can see on the OpenSimulator console, the viewer requesting the throttle set lower and higher as network conditions change. When a user logs in to a Simulator for the first time and has the bandwidth slider at 1.5m, they're prone to having missing prim (prim not displayed but, physics wise, if your character hit one of these prim that your viewer didn't get an update, it would be there). Subsequent logins seem to work fine regardless, though it can take longer. (There's less to download in a sim once you've already been there[textures are cached, uuids are cached, etc]) When a user sets the throttle at 300-500, they enjoy the best experience. When a user sets the throttle to 1.5m and their connection is barely able to support a low connection of 250KB, they have the poorest experience. Additionally, it adds processing overhead on the UDP stack, Memory, and processor of the Simulator machine serving them. This, depending on the quality of the connection and the things that the client requests can become enough of a strain to bring the quality of the simulation down for everyone in some situations. This has been resolved recently, however, in the past, a single user experiencing connectivity issues with an improperly set throttle re-requesting images over and over again could consume 500MB worth of packet data queued up in the throttle system. Additionally, this could produce a situation where too many acks are appended to a packet. :) The moral of the story is, set your bandwidth slider as close to your functional connection speed to linden lab's network as you can. If you set it too low, things will come in slow and queue up in the memory of the server (reducing the available memory for other things). If you set it too high, your packets will get lost on a router somewhere between Linden Lab's servers and your computer. This will trigger the UDP Resend functionality... and consume memory and processing time on the server. Just because your Internet connection is really fast, doesn't necessarily mean that your connection from your computer to Linden Lab's servers is fast. If you set the network slider higher then your actual speed there, your experience will degrade. The client will attempt to compensate for it, but it will not always succeed. Regards Teravus On 6/23/09, Tigro Spottystripes <[email protected]> wrote: > > > Colin Kern escreveu: > > On Tue, Jun 23, 2009 at 1:08 PM, Joel Foner<[email protected]> wrote: > > > >>> That said, an awful lot of people crank the bandwidth up to 1.5mbps > >>> because they figure they have a 1.5mbit connection or better. That's > >>> often a mistake. Most ISPs overstate the capacity their networks by a > >>> good margin, and it's very unlikely that even a 3 mbit DSL connection > >>> provides highly reliable 1.5mbit downstream. > >>> > >> But for most on cable or fiber it's only a part of what's available :) Is > >> there a reason it's capped at 1.5Mbps? > >> For what it's worth, an easy place to check your actual bandwidth is here > >> http://www.speedtest.net/. > >> Joel > >> > > > > I noticed in Snowglobe the cap is much higher (6 mbps, IIRC). > > > > I have heard some people saying that lowering your bandwidth helps > > with "rubber-banding", which I think makes more sense. If your > > bandwidth is too high, it might overload your own internet connection, > > causing latency problems. > > > > Colin > > > With me, somthing I've noticed, usually when I have any noticeable > packetloss, if I move the bandwidth throttle all the way down for a few > (or several) seconds, the packetloss goes away, once it is gone I can > move the throttle back up and packetloss doesn't seem to return (either > until another login, or at least for a long time), there a few rare > times where doing this doesn't have any effect on the PL though, I > imagine that it has a different cause in these cases (I haven't tried > Snowlobe yet) > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
