[Opensim-dev] Does OpenSim need to leave so many packets marked as reliable?

Justin Clark-Casey jjustincc at googlemail.com
Thu Oct 2 19:36:09 UTC 2008


Hmm, yes

By the way, you may want to ignore my earlier yammerings - I'm not able to reproduce consistent numbers at the moment - 
the 95% I had might have been an anomaly.

The best thing to do is probably to look at which packets the Linden grid is marking as reliable and do the same thing 
for now, if we are actually doing anything different.

Dahlia Trimble wrote:
> I seem to recall there was once a discussion about using UDP vs TCP for 
> sim<->viewer communication, and one of the arguments against TCP (I 
> believe it was a LL employee's opinion) was that the sim network stack 
> would easily become overloaded managing all of the packets that  it 
> would have to deliver reliably in the case of network problems, and this 
> could easily use up all the available memory in the server machine and 
> bog it down. The advantage to UDP in this case would be the ability to 
> discard packets where the information was no longer timely. I suspect 
> something similar may apply in the case of overzealous use of the 
> reliable flag as well.
> 
> 
> 
> On Thu, Oct 2, 2008 at 11:59 AM, Justin Clark-Casey 
> <jjustincc at googlemail.com <mailto:jjustincc at googlemail.com>> wrote:
> 
>     Hmm, I then did the obvious thing and compared it (unscientifically)
>     with a couple of sessions on the Linden Lab grid.
>     There, reliable packets appear to compromise approximately 40% of
>     the transfer.
> 
> 
>     -------- Original Message --------
>     Subject: Does OpenSim need to leave so many packets marked as reliable?
>     Date: Thu, 02 Oct 2008 19:32:57 +0100
>     From: Justin Clark-Casey <jjustincc at googlemail.com
>     <mailto:jjustincc at googlemail.com>>
>     To: opensim-dev at lists.berlios.de <mailto:opensim-dev at lists.berlios.de>
> 
>     Hi there,
> 
>     A vast number of the packets that we send out from OpenSim (usually
>      >95% according to the statistics printed to the
>     Linden viewer log on shutdown) are marked as reliable.  This
>     requires that the viewer respond with an ack, and it just
>     doesn't appear that this is done very well when a large number of
>     reliables are sent.  A lot of acks never come and we
>     often appear to end up resending thousands (or in the worst case
>     tens of thousands) of packets.
> 
>     In a private experiment I've set Header.Reliable = false for the
>     LayerDataPacket and ObjectUpdatePacket (which appear to
>     be the greatest sent by count, and which are currently reliable by
>     default in libOMV).  Naturally, this cuts down the
>     vast number of resends (and possibly some of the packet_out_of_order
>     messages that come out on the console log) without
>     any apparant ill effects.  However, my testing has been pretty
>     limited so I'm minded to wait until Monday before making
>     any trunk changes, since then I can get a better load test with
>     multiple avatars (this doesn't stop anybody else testing
>     of course :-)
> 
>     Any opinions on this?  Is there a good reason for these packets to
>     remain reliable (when resends are probably rare
>     anyway)?  libOMV appears to mark every packet as reliable by
>     default...  and then OpenSim removes this from a couple of
>     them but not from others.
> 
>     --
>     justincc
>     Justin Clark-Casey
>     http://justincc.wordpress.com
>     _______________________________________________
>     Opensim-dev mailing list
>     Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
>     https://lists.berlios.de/mailman/listinfo/opensim-dev
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev


-- 
justincc
Justin Clark-Casey
http://justincc.wordpress.com



More information about the Opensim-dev mailing list