[sldev] Client bandwidth and server lag

Teravus Ovares teravus at gmail.com
Tue Jun 23 14:21:26 PDT 2009


@TigroSpotty
I did not attempt to explain why your packet loss doesn't return when
you move the slider back up.    However, since we're on this topic
now, I would suggest that the viewer cache may have something to do
with requesting less stuff.

@Colin

Yes.    The packets have to be queued up somewhere and there needs to
be a process within the simulator to figure out how much of that queue
to send at least once a second.      Additionally, the UDP protocol
employs what is known as a 'resend' for reliable packets.    This
means that it will wait for an 'ack' from the client before tossing
the packet out.   If it doesn't get an ack back, it will be queued up
to be sent to the client again in the resend 'throttle' slot.    The
resend functionality takes more 'resources' to do then the throttle
queues.   This is especially evident under load.

Regards

Teravus

Regards

Teravus

On 6/23/09, Tigro Spottystripes <tigrospottystripes at gmail.com> wrote:
> I'm sorry, but how does that explain packetloss not returning when I
> move the slider back up?
>
> Teravus Ovares escreveu:
> > 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 <tigrospottystripes at gmail.com> wrote:
> >
> >> Colin Kern escreveu:
> >>
> >>> On Tue, Jun 23, 2009 at 1:08 PM, Joel Foner<joel.foner at gmail.com> 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
> >>
> >>
> >
> >
>
>


More information about the SLDev mailing list