[Swift-devel] Try coaster on BG/P ?

[Mihael Hategan]

On Thu, 2008-06-19 at 18:50 -0500, Michael Wilde wrote:
> On 6/19/08 6:19 PM, Ben Clifford wrote:
> > Probably would want to launch from somewhere else the coaster head node 
> > job and the coaster workers all in one go, by the sound of how things work 
> > on BG/P. The only mode that I've used coasters in so far doesn't do that - 
> > the coaster head node job launches workers as it percieves they are 
> > needed. Where you're being allocated a big chunk of the machine, it 
> > probably makes sense to run coasters on all of that chunk at once.
> 
> Yes, makes sense.
> 
> The BGP mechanism works as you say - the head-node job starts first, and 
> when it exits from its main process the BGP startup mechanism launches 
> the worker-node jobs. The server continues on the head node (the ION in 
> this case) asynchronously.
> 
> Whats the form of the coaster head-node job? Is that Java, or some form 
> of script? (I recall Java, but keep forgetting).

Bash forks Java.

> 
> On the BGP, if the worker jobs connect back to the headnode process, 
> then it may be as easy as just starting them, with the right contact 
> info to reach the headnode.

That's how it works.

> 
> Do you think Swift/Coaster will scale well if it had up to 640 servers, 
> one for each p-set of 256 compute cores? Thats one "natural" mode of 
> deployment.

Experience will tell.

> 
> Another mode is N servers total, where N can be any small number >=1, 
> but these N servers would run on a login node.

Is there a purpose to that? 'Cause to me it sounds more like trouble
than goodness.