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.

-Brian


-------------------------------------------------------
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