[Opensim-dev] forcing some load, kicking the tires

[Stefan Andersson]

Some things needed to be done with packet handling;
 
* The outbound UDP queue should be discarded immediately unless somebody can think of a really good and valid point why you'd want to send UDP packets in order (they will reach the client in a jumbled order anyway)
* We need to think hard about (discuss) whether update packes are supposed to be 'reliable' (acked) or not, and how that affect system design. ie, how acked packs could (or should) influence what is sent in the next packets.
* The severe rubberbanding issues implies that either the client is dumb (don't keep track of update sequence numbers per objects) or we're doing something wrong (ie updates are supposed to be reliable but aren't or vice versa) - I don't know which is the case.Regarding the update sweeps;
The current model is that we have a few timers causing objects to be scheduled for terse or verbose updates.
We then have a regular update sweep that runs over then, filters out the most pressing update needs (today based on how stale the change is) for each client (presence) then create packets for these updates and sends them.
 
I'd say the key here is to find a good (algorithmic) balance between load for updating (ie frames/sec) and number of update packets sent per client per second - how precise change should be simulated vs how precise it should be communicated. It seems prudent to separate these two, and the timer thresholds should be based on how fast change is simulated for the client(s) that has full interest in it.
 
/Stefan



> Date: Fri, 9 Nov 2007 08:44:05 -0800> From: mic.bowman at intel.com> To: opensim-dev at lists.berlios.de> Subject: Re: [Opensim-dev] forcing some load, kicking the tires> > > in order to test some aggregate networking issues, we have a standalone> server (current trunk version from svn, no physics, xp, core duo, 4G,> ...) where we are moving a bunch of objects around inside a fixed> region. each object is running a script with a timer event that fires> every 1-3 seconds and the object moves to a random position using> llsetpos (so there are no collisions). this set up gives us the ability> to generate scalable and almost reproducible loads (at least for object> updates).> > with 30 objects in motion, the server runs < 30% load, cyclical (athough> the peak loads occur at about 15 second intervals so i'm not sure how> that correlates to timer events). with 100 objects in motion the server> load peaks at around 75% (memory image is around 800M consistently).> however, with 100 objects in motion, the bandwidth to the one user> currently connected goes to (almost) 0, with periodic (every 10 seconds> or so) big bursts of updates. > > --mic> > > > -----Original Message-----> From: opensim-dev-bounces at lists.berlios.de> [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Sean Dague> Sent: Friday, November 09, 2007 7:41 AM> To: opensim-dev> Subject: Re: [Opensim-dev] forcing some load, kicking the tires> > On Fri, Nov 09, 2007 at 10:31:09AM -0500, Sean Dague wrote:> <snip (56 lines)>> > > > * We need to change the way Terse Updates out of the physics engine> > works. (Teravus already committed code here, see the email is out> of> > date already!)> > Well, at least part of this note is out of date even as I wrote it, as> after this change there is a dramatic CPU improvement. Previously the> environment had a 15% CPU usage baseline just handling the physical> prims that were stopped. That is now removed, and I've actually got> OpenSim running 0% in most cases, a couple percent if I walk around> playing soccer with things, which all drops nicely back to 0% within 10s> of not doing anything.> > -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.> __________________________________________________________________> _______________________________________________> 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/4bccc10a/attachment-0001.html>