[ptp-dev] Some questions about runtime model,sdm

[yang ke <jodiusyk@xxxxxxxxx>]

Hi,all
I ' ve just managed to launch a parallel job across multiple nodes by a small change in orte_server.c. :-)

I know that our v1.1 is coming in the near weeks, and it has been made great change from v1.0, still I have some questions, hope it will be helpful.

 

1. About Runtime Model
Nathan, I think asychronous updating will be better for the runtime model esp. for job launching.  Currently we use a <RUN ...> command follwed by a <GETPATTR ...> command to BLOCKLY launch a job and then to construct its job structure,  which often makes the user staring at a Progress Bar for a boringly long time to go on operate.  The runtime can quickly return a job id, but other attributes,like process pid(real pid),would not be returned soon(maybe after all tasks launched). We can make better use of this knowledge for finer monitoring of job status: process status.
      First construct the job structure on higher layer model(java),then LISTEN to lower layer(such as slurm or orte) to return attribute events.The lower layer should have good sense of process attributes and status changes, and report process attributes and status changes timely. Anytime there occurs some error,we can find out which process fails instead of a whole job error.
      I have tested that on SLURM,but I doesn't know if ORTE supports such process status report.Will we get such changes?

 

2. About Scalable Debugger Manager

recently I study a paper-
 "Extending a traditional debugger to debug massively parallel applications",Susanne M.Balle,Journal of Parallel and Distributed Computing 64(2004) 617-628

 

It suggests some good practice on improving debugging preformance.
PS: Greg's "architeture of a parallel relative debugger" is listed in the References. :-)

 

I looked into the source of sdm, and I am afraid sdm client may be a bottleneck when issuing debug instructions to servers and receiving debug responses from servers, for it has to finish a set of processes one by one. If we are to debug 10K processes, sdm client will be busy dispatching a deubg instruction and will be buried in a flood of reponses. Fortunately, implementation of sdm  in MPI way fills me with courage. We can dispatch debug instructions in a way similar with MPI_BCAST() and aggregate debug responses with MPI_GATHER(). Alternately, we can adopt some idea from Susanne's paper,for example,we use a tree-like network to dispatch and aggregate.

 

Again,from that paper, I find out there are 3 types of debugging messages:
Type1------Identical outputs from each of the debugger/aggregators
Type2------Identical outputs apart from containing different numbers
Type3------Widely differing outputs
sdm has made Type 1 aggregations,using hash table(so cool!),but Type 2 still needs to be aggregated,so I hope future sdm work out some way to aggregate Type 2 messages.

 

3. About Open MP debugging support

PTP now supports MPI debugging well.Does future PTP support Open MP debugging? If so, how?
Can we still use gdb?
Hope to see ptp v1.1 soon, and good luck to you.

---

How low will we go? Check out Yahoo! Messenger’s low  PC-to-Phone call rates.