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, things tend to work far better. With no caps at all, performance gets very unpredictable. The variance in times between pulling updates from the entity update queues goes up significantly. With a cap, you don't get all the updates as fast... but the performance is more predictable (and the user experience didn't degrade much). I'm not at all sure what to make of that... it could be kernel or network buffering issues. I just don't know. --mic On Mon, Mar 28, 2011 at 11:41 AM, James Hughes <jam...@bluewallgroup.com>wrote: > > 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 > bufferbloat and dark buffers in the Internet. I posted links to the > information in IRC and would like to add it here as well ... > > http://www.bufferbloat.net/projects/bloat/news > http://mirrors.bufferbloat.net/Talks/BellLabs01192011/ > > I think this issue may a lot of bearing on our networking in the open > Internet where packets in-transit are routed through devices with large > built-in buffering. The packets are held in these devices for forwarding > at a time that seems convenient for the device, rather than using > congestion management and dropping the packets when needed. It is > possible that a packet may experience this several times in-transit. As > the packets are held in the buffers, latency is added to the circuit and > may reach the point where we resend packets because we didn't get the > acknowledgment in time. > > Hopefully this is, at least, somewhat related. > > Thanks, > BlueWall > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev >
_______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
