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

[Michael Wilde]

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

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.

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.

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

The issues seem to be connectivity, reachability (having all the 
components find out how to reach each other), and then performance (how 
will the algorithms behave in the different topologies).