Re: [Blockbuster-devel] Blockbuster microupdate released

[Rich C. <rc...@ll...>]

On Feb 13, 2008, at 7:05 AM, Sean Ahern wrote:

> I think all of us who will be doing development on blockbuster  
> should check that we are members of the blockbuster developer  
> mailing list at SourceForge.  That will likely be the best place to  
> continue technical discussions about project direction.
>
> Rich Cook wrote:
>> You convinced me.  I'll move in that direction (MPI).   This  
>> synchronization thing has become pretty high priority here.  It's  
>> not that hard, actually, so let's see what happens this week.
>
> Okay.  We're not going to get a chance to play with it for a few  
> weeks, like I said, so we're not in a hurry.

Stay tuned

>
>> Agreed that staying on the same branch is desirable.  At the same  
>> time, let's recognize that this will require more communication  
>> and thus a slightly higher level of project management on both ends.
>
> True enough.
>
>> Furthermore note that resources are scarcer around here than used to
>> be, so there may be lags in progress occasionally on my end.
>
> That's okay.  I understand.  :-)

Becky has mentioned we might be able to add someone to help me with  
graphics support to enable more blockbuster progress.

>
> -Sean
>
> __
> Sean Ahern
> Oak Ridge National Laboratory
> AIM: ornlsean
> 865-241-3748
>> On Feb 12, 2008, at 1:45 PM, Sean Ahern wrote:
>>> Rich Cook wrote:
>>>> I am going to tighten up frame sync on the next iteration.  I  
>>>> tentatively plan to create a barrier right before the slaves  
>>>> actually call glSwapBuffers, and to use TCP sockets instead of  
>>>> MPI, to avoid rewriting the code that launches the slaves, and  
>>>> to avoid the problems that arise from the variety of MPI  
>>>> launching schemes out there.  I would actually like to rewrite  
>>>> the slave launching code, but it's a longer path.
>>>
>>> I definitely want to go down the MPI path.  Our current wall has  
>>> 14 slave nodes.  Our new cluster will have 27.  That's just too  
>>> slow for a TCP-based method.  Any communication method based on  
>>> MPI will be orders of magnitude faster than a TCP-based one.  Not  
>>> just for launching, but for synchronization, too.
>>>
>>>> Let me know what you're planning.  Perhaps we should branch or  
>>>> something?  I'm not sure how to blend our efforts effectively  
>>>> but it will be nice to get your contributions, thanks!
>>>
>>> I'm not sure how to blend efforts either.  Let me draft up an  
>>> outline of the work we hope to do, and we can see how it might  
>>> merge.  At the worst, making an SVN branch would work.  We can  
>>> set up an ORNL repo here, I suppose, and then sync up with you at  
>>> a later point.  But I'd rather keep things synced up between LLNL  
>>> and ORNL.  We can benefit from each other's modifications.
>>>
>>> -Sean
>>>
>>> __
>>> Sean Ahern
>>> Oak Ridge National Laboratory
>>> AIM: ornlsean
>>> 865-241-3748

-- 
✐Richard Cook
✇ Lawrence Livermore National Security
Bldg-453 Rm-4037, Mail Stop L-557
7000 East Avenue,  Livermore, CA, 94550, USA
☎ (office) (925) 423-9605
☎ (fax) (925) 423-6961
---
Information Management & Graphics Grp., Services & Development Div.,  
Integrated Computing & Communications Dept.
(opinions expressed herein are mine and not those of LLNS)