Over the last several weeks, Dan Lake I have been looking some of the
networking performance issues in opensim. As always, our concerns are with
the problems caused by very complex scenes with very large numbers of
avatars. However, I think some of the issues we have found will generally
improve
Here are a few facts that I've personally discovered while working
with LLClientView.
1. It has been noted that people with poor connections to the
simulator do consume more bandwidth, cpu, and have a generally worse
experience. This has been tested and profiled extensively.This
may seem
Hi,
sounds great.
Some things to consider:
- Some actions require explicit sending of a packet which is an
update packet, but is used for special cases. Sit, stand, changing
group tags, creating/joining groups are all such cases where special
care needs to be taken.
- Resend is evil for static
Thanks Mic,
I look forward to testing this. I have been chasing network issues that
show up as wildly different performance experienced by users that are in
the same simulator with others having similar connections and
workstations. A couple of weeks ago I heard about something called
No, we can't discard small changes. As the avatar comes closer, they
would be seen out of place, e.g. someone building in the distance
would move prims and then you come closer to look and all prims
would be out of place.
Melanie
Dahlia Trimble wrote:
a couple thoughts..
Perhaps resend
I believe the buffer-bloat problem is more related to TCP than UDP. UDP is
probably affected as some ISPs may choose to discard UDP traffic when
excessive congestion occurs.
On Mon, Mar 28, 2011 at 11:41 AM, James Hughes jam...@bluewallgroup.comwrote:
Thanks Mic,
I look forward to testing
For avatars yes. But prim updates can never be discarded, no matter
how trivial, because they establish new persistent state.
Melanie
Dahlia Trimble wrote:
the viewer discards small changes anyway if avatar imposters are enabled
On Mon, Mar 28, 2011 at 11:54 AM, Melanie mela...@t-data.com
yes, which is why I said discard them when new updates occur.
On Mon, Mar 28, 2011 at 12:03 PM, Melanie mela...@t-data.com wrote:
For avatars yes. But prim updates can never be discarded, no matter
how trivial, because they establish new persistent state.
Melanie
Dahlia Trimble wrote:
the only thing we've touched so far is the entity update queue. that's all
avatar updates prim updates. we haven't touched any of the other packets.
the resend focus would be for prims avatar updates only.
--mic
On Mon, Mar 28, 2011 at 11:19 AM, Melanie mela...@t-data.com wrote:
Hi,
sounds
Yeah... and i think it was your post that got us thinking about how the
multiple layers of buffering were hurting performance here. thanks for the
original post.
In poking around at this issue... one thing I've found (completely
anecdotally) is that when we put a reasonable cap on per client bw,
comments below...
On Mon, Mar 28, 2011 at 11:49 AM, Dahlia Trimble dahliatrim...@gmail.comwrote:
a couple thoughts..
Perhaps resend timeout period could be a function of throttle setting
and/or measured packet acknowledgement time per-client? (provided we measure
it). That may prevent
On 03/28/2011 03:27 PM, Mic Bowman wrote:
Yeah... and i think it was your post that got us thinking about how
the multiple layers of buffering were hurting performance here. thanks
for the original post.
In poking around at this issue... one thing I've found (completely
anecdotally) is that
I'm not sure how often the viewer adjusts but I have seen message on the
linux viewer console which mentioned throttle adjustments. At the time they
seemed quite frequent, perhaps in tens of seconds between messages.
On Mon, Mar 28, 2011 at 12:34 PM, Mic Bowman cmick...@gmail.com wrote:
I have been testing this on my 16 region mega region sandbox on OSgrid, I
have noticed that my Racer performs much better than it has in the past,
alot less slow downs and jerky behavior. Great stuff so far, I can not wait
to see more, Thanks Mic and everyone at Intel Labs.
On Mon, Mar 28, 2011
14 matches
Mail list logo
