Re: Deadlock problems in binaryswap spu?

> Joel Welling wrote:
> > Brian Paul wrote:
> > 
> >>Hi Joel,
> >>
> >>If each compute node is going to talk to just one binaryswap node, why 
> >>use tilesort?  I guess I don't see the need for tilesort at all in 
> >>this config.
> >>
> > 
> > Well, the idea was to be able to dial up and down the number of tilesort
> > servers as I experimented with the configuration, but as you say it 
> > wasn't working because the barriers had been broadcast to all servers.
> > I had tried some experiments using just a 'pack' spu, but apparently
> > not enough of them...
> > 
> > 
> >>As for the error, if your parallel app is creating a barrier of size N 
> >>(N=4?), the tilesort SPU will broadcast the barrier to all the 
> >>crservers.  If the crserver has less than N clients, it'll deadlock.
> >>
> >>The tilesort SPU broadcasts barrier commands because that's what you'd 
> >>want to do if you were doing parallel tilesort (M tilesort nodes all 
> >>talking to N rendering nodes).
> >>
> >>Barriers, however, become tricky to use in a multi-tiered 
> >>configuration (ex: 3 tiers of nodes A->B->C).
> >>
> >>One thing you might try is the crserver option to disable/ignore the 
> >>parallel API (barrier/semaphore) calls:
> >>
> >>	servernode.Conf('ignore_papi', 1)
> >>
> > 
> > That does indeed do the trick, in combination with use of a 'pack' spu
> > rather than tilesort!  I'd wondered what that option was good for; I guess
> > now I know!
> 
> Next, could you remove the pack SPU?  That is, just put the binary 
> swap SPUs on the application nodes.  That'd save a network hop.  I'm 
> assuming you have suitable graphics hardware on the app nodes.
> 

Ah, that's the rub- the app nodes have no graphics hardware.  These are supercomputer nodes, and they're being assigned 'helper' nodes with graphics hardware on the fly.  I was hoping that using this configuration would allow me a larger 'fan-in' between app nodes and rendering nodes, but so far that doesn't seem to be the case.

-Joel



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642