I think you want to set up three independent compounds, like in hactar.rc.eqc. Maybe you'll find it easier to use a projection instead of a wall to configure your overlapped setup. I don't think you need input and output frames.
On the control host I would just use a fourth channel with a symmetric wall. As for the hang, a stack trace would be most helpful. IP-over-IB is a precondition to SDP. If you don't use LD_PRELOAD, you most likely have IP-o-IB. You can verify your performance using the netperf tool shipping with Equalizer (see IB doc on website for details), with SDP you'll get much better performance. dm-jp wrote: > > I believe to be running in IP over IB (I can reach the other nodes as I > would on ethernet). I will build a debug version and attempt to do as you > suggest. There is a limited amount of interaction beforeit freezes and in > most cases it stalls the hanging by a few seconds (when first run it can > last well beyond 30 seconds of interaction). > > As for the non-contiguous areas of the channels, the overlapping is on > purpose (as far as channels 1-3 are concerned). I assumed that this is how > you define blending (we use a Fakespace > http://www.mechdyne.com/integratedSolutions/displaySystems/products/CURV/CURV.htm > CURV setup). I tried to setup channel 0 to be simply a preview window for > interaction on the master node butI think I am getting confused. For this > I used the configure tool and got just a quick idea on how thie config > file works but I'll read the programmer's documentation to see what I'm > doing wrong. > > Thank you. > > P.S. Yes I am using Linux (it's a cluster of CentOS nodes, using the Rocks > Cluster distribution) > > > Stefan Eilemann wrote: >> >> Hello, >> >> I haven't seen this kind of hang for a long time, but it is possible >> that there is still some bug in the networking code. It sounds like a >> race condition resulting in a deadlock. We haven't tested it too >> extensively on InfiniBand, which might be the reason for it surfacing >> now. >> >> I assume you are using Linux? >> >> Does eqPly freeze after rendering a few frames? >> >> Is it random, or can you tie the freeze to some user interaction? >> >> Do you use IP-over-IB or SDP? >> >> Can you reproduce the bug in a debug build? (set CXXFLAGS to '-g' and >> recompile) >> >> If yes, can you attach to the Equalizer processes with gdb and send a >> stack trace of all threads? Please also send the log files (~/ >> tile*.log). >> >> I think it is best if you open a bug and attach the above information >> to it. >> >> >> Your config looks weird - your destination channel 'channel0' renders >> into the full viewport, and then gets overlapping input tiles from the >> other channels? Is this intended? Also the viewports for >> channel1...channel3 are not contiguous. >> >> >> The master channel 'channel0' defines the viewport for all child >> compound channels. What are you trying to configure? Did you read the >> Compound section in the Programming Guide? >> >> >> >> Cheers, >> >> Stefan. >> >> >> _______________________________________________ >> eq-dev mailing list >> [email protected] >> https://in-zueri.ch/cgi-bin/mailman/listinfo/eq-dev >> http://www.equalizergraphics.com >> >> > > -- View this message in context: http://www.nabble.com/Freeze-problem-on-multiple-nodes-tp17956853p17988940.html Sent from the Equalizer - Parallel Rendering mailing list archive at Nabble.com. _______________________________________________ eq-dev mailing list [email protected] https://in-zueri.ch/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
