Hi Carsten, thank you for sharing your experiences and suggestions.
In our case we usually have control over network settings and computer configurations ( 99.9% of the times running some linux flavor ) so the issue at least here doesn't seem to be related to some weird configuration.. Really good to know that there is co::global where I can play around with the settings -- I will definitely give it a try and come back with any results I might have.. As for the suggestion to move some logic to the clients is something that I am already doing quite a lot in the cases that I can actually do it but as you also mentioned, unfortunately this is not always the case.. Now for example I am implementing some particle streams for generative visuals on a media installation and I am hitting these kind of limitations… I will try out though some stuff and will report back any findings.. Cheers, Petros On Nov 27, 2014, at 8:30 AM, ROHN Carsten <[email protected]> wrote: > Hey Petros, > > I don't have experience with a large number of objects getting updated, but > with big object updates (like a texture update every frame). Multicast > performs a lot better in this scenario than unicast, obviously especially > with a higher number of clients. > > We have customers where multicast is not performing well, same as you > describe it. I assume this is due to network parameters or the software > environment (traffic sniffer aka virus scan!). That's why multicast might be > a viable solution for a network, where you have full control over the network > and computers, but not if you want to roll it out to different (customer) > clusters, in my hard-earned experience. > > There are also quite a number of parameters to tweak (co::global), which > optimize the behavior of the protocol regarding packet loss. In my experience > it makes sense to set the MTU smaller (~10k, on windows), the ack timeout to > 5 or even 10 and set the scale down parameter bigger than the scale up > parameter(2-3x). You might get a more smooth behavior. > > In general, if you have a lot of object updates it might also be worth to > move some logic to the clients and calculate object changes there. In other > words, to distribute more high level data (less data, less objects) instead > of the most low level data. Yes, unfortunately it's not possible in every > case. > > Cheers, > Carsten > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Petros Kataras > Sent: Mittwoch, 26. November 2014 22:44 > To: Equalizer Developer List > Subject: Re: [eq-dev] RSP / mutlicast details > > Hi Stefan, > > there was a follow up on this post -- The weird object command issue was due > to my fault (..a leftover from not resolving carefully a merge conflict on a > specific file..) This is fixed and I am not getting the specific error > anymore.. > > I was able to run properly the RSP configuration but as I mentioned on the > previous post purely qualitatively ( I didn't do any actual measurements ) > the unicast approach still seems smoother so I am sticking with this for now.. > > Right now I am dropping from 60fps to around 40fps if I go with more than 200 > distributed objects that get updated every frame ( i.e syncing a position for > example ).. This is locally with 1 master and 1 slave running on the same > machine.. > > I would be interested in any experiences people might have, dealing with a > large number of shared objects that need to be synced very often and of > course any suggestions for a more optimized path are always welcome.. > > Although I understand that in these cases application specific > parameters/requirements play a critical role also .. > > I will try out some stuff now that we have this setup here and report back > any findings.. > > Best, > Petros > > > > On Nov 26, 2014, at 4:59 PM, Stefan Eilemann <[email protected]> wrote: > >> >> On 21. Nov 2014, at 17:12, Petros Kataras <[email protected]> wrote: >> >>> I have a shared object that actually seems to map and work fine but I get >>> an LBUNREACHABLE from objectStore.cpp line 700 . Reading through the source >>> I can't figure exactly where the issue might lie and as I mentioned the >>> object seems to register and map properly on the master and client side >>> respectively.. >> >> When does this happen exactly? The node crashing receives an object command >> for a specific instance which can't be found. This is most unusual. I've >> added more debug output, can you try with '[master f941a79] Increase error >> output'? >> >>> >>> Besides that I am also getting a segfault when exiting the app inside >>> EventConnection::getNotifier() when running the RSP config. This segfault >>> happens also with eqPly / seqPly and so on but I don't really have time to >>> debug it right now... >>> >>> Anyways I think for now I am gonna stick with unicast and maybe later on I >>> ll give it a try again.. >> >> My recommendation would also be to only use multicast if you have a serious >> bottleneck in distributing data. The technology is simply not mature. >> >> >> >> Cheers, >> >> Stefan. >> >> >> _______________________________________________ >> eq-dev mailing list >> [email protected] >> http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev >> http://www.equalizergraphics.com > > > _______________________________________________ > eq-dev mailing list > [email protected] > http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev > http://www.equalizergraphics.com > This email and any attachments are intended solely for the use of the > individual or entity to whom it is addressed and may be confidential and/or > privileged. > > If you are not one of the named recipients or have received this email in > error, > > (i) you should not read, disclose, or copy it, > > (ii) please notify sender of your receipt by reply email and delete this > email and all attachments, > > (iii) Realtime Technology does not accept or assume any liability or > responsibility for any use of or reliance on this email. > > For other languages, go to http://www.3ds.com/terms/email-disclaimer > > _______________________________________________ > eq-dev mailing list > [email protected] > http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev > http://www.equalizergraphics.com _______________________________________________ eq-dev mailing list [email protected] http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
