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
