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
