[Opensim-dev] [Opensim-commits] r2309 - trunk/OpenSim/Region/ClientStack

[Teravus Ovares]

One more item to note, I've exposed PhysicsActor.ThrottleUpdates, which,
when set to true, will cause physics to send out an update on whatever actor
every 2/3 world frames, vs every one until the prim comes to rest.  (terse
updates caused by physics are only sent out when there's a significant
update now, however, you can throttle it more by using the
PhysicsActor.ThrottleUpdates member.

At some point in the future, I might throw a parameter into the physics
update event..    for 'Must be Sent' vs 'it's okay to drop'.   The 'settled'
update from physics must be sent(or prim will stay in motion on the client),
while general movement can be dropped and not degrade the client experience
much.


On 11/9/07, Sean Dague <sean at dague.net> wrote:
>
> On Fri, Nov 09, 2007 at 10:30:20AM +0800, Adam Frisby wrote:
> > Alright,
> >
> > I've implemented a throttling scheme a little, here's how it works:
> >
> > * In the central ClientLoop() in the UDP clientview it now checks to see
> > if the user is over a specified throttle limit, if it is, it will
> > requeue the outbound packet (I'm assuming PacketQueue is FILO)
>
> I'm not sure that this is going to help all that much, those packets
> still need to get out.
>
> > * If we queued the last packet, and we are processing something like
> > that again, sleep 100ms to prevent a infinite spinlock.
>
> If we only have 1 packet to send, why wouldn't we send it?  I think this
> is going to make the situation worse.  Based on what I saw yesterday, I
> think this would have made the situation fall down much worse.
>
> > In theory this should help out a little during high transfer periods.
>
> I think this is the wrong place to optimize right now.  What we really
> need to do is to figure out how to send less packets.
>
> Yesterday we had a nice test of the system.  Dual 3.6 Ghz box, 4 GB of
> RAM.  With ODE enabled we were able to get about 20 AVs before it was
> running > 100% CPU.  (I'll have to figure out how many physical prims we
> actually had there.)
>
> Once we were at 130% utilization there was at least a 2 second lag in
> movement updates, new users couldn't connect, and chat was laggy like it
> does on the main grid.
>
> If we are going after perf issues, let's not do subtle hackes on the
> packet queue, but actually figure out where we don't really need packets
> being generated in the first place.
>
>     -Sean
>
> --
> __________________________________________________________________
>
> Sean Dague                                       Mid-Hudson Valley
> sean at dague dot net                            Linux Users Group
> http://dague.net                                 http://mhvlug.org
>
> There is no silver bullet.  Plus, werewolves make better neighbors
> than zombies, and they tend to keep the vampire population down.
> __________________________________________________________________
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFHNFRhSamXem9TdyYRAitCAJ4ruB6ymKfA2VHHQcokUK0H9QOmqgCdHV0y
> 9d/6nuMFIm23pOHjsNYj8Rk=
> =+8YX
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20071110/6c1213b7/attachment-0001.html>