Re: [ptp-dev] PTP enhancements to support LoadLeveler

[Dave Wootton <dwootton@xxxxxxxxxx>]

Greg
For tooltip text, how are you planning to display multiple attributes? Are 
you thinking of something along the line of 'attrname=attrvalue'? That 
might be ok, although we would probably add our own attribute to the set 
rather than using xxxExtraState to get a more meaningful label for the 
attribute. Is there a way to force newlines in tooltip text (\n)? We think 
that would make the text more readable in the case where there are 
multiple attributes displayed. We also would like the ability to delete 
attributes from the displayed set as you suggest.

For job/node status, our concern is the volume of data sent for a job or 
node status change will be large. We could have as much as 40 lines of 
text per update, and that in most cases, the user isn't interested in 
seeing this. For single jobs, this wouldn't be too bad, but at PTP 
startup, with a LoadLeveler queue that has hundreds or thousands of jobs 
in the queue, that's a lot of information being sent. If something happens 
that results in lots of status updates, we have the same risk of high data 
volume. 

Maybe we are being too cautious about data volume, but we think that if we 
have a command/event response for this data, we avoid the data volume 
problem.

Dave



Greg Watson <g.watson@xxxxxxxxxxxx> 
Sent by: ptp-dev-bounces@xxxxxxxxxxx
07/18/2007 02:19 PM
Please respond to
Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>


To
Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
cc

Subject
Re: [ptp-dev] PTP enhancements to support LoadLeveler







On Jul 18, 2007, at 12:54 PM, Dave Wootton wrote:

> We have some success now with seeing job and node status from 
> LoadLeveler
> in the PTP views. There are some enhancements we think would be 
> useful to
> LoadLeveler and other resource managers as well as some questions
>
> Suggestions
>
> 1) LoadLeveler has a number of statuses for a job and node beyond the
> simple running and exited that I am using for PE. We originally talked
> about adding additional icons or different colored icons to represent
> those statuses, but we think there are too many for this to be a good
> idea. We're thinking that if the job and machine view could be 
> enhanced to
> allow flyover/tooltip help for each icon in the view. That text 
> could be
> used to display additional status. We are also thinking this status 
> would
> be sent from the proxy as an additional, optional, attribute to 
> node and
> job change events. Each time job or node status changed we would send
> across a new event. The tooltip text would present whatever thye last
> additional status for that node or job was. It might make sense to 
> extend
> this to machine and task objects as well, but we don't have a need for
> these to support LoadLeveler.

Nodes already have a 'nodeExtraState' attribute that can be used to 
change the node icon to reflect additional job-scheduler related 
states. I could extend this to any model elements that are normally 
displayed as icons. Currently the tooltip for nodes shows the 'name' 
attribute. It would probably be nice if the attributes that could be 
displayed in the tooltip were customizable, and also available on any 
model element as well.

Off the top of my head, here's what we could do:

1. Add an 'xxxExtraState' attribute to each model element. This is 
just so there is something there already.

2. Add a tooltip attribute to each model element. This would be a 
string set containing the names of attributes to display in the 
tooltip. The presence or absence of this attribute would turn 
tooltips on or off. Now I think about it, I'm not sure there is any 
way to *remove* an attribute. We may have to add something.

3. Add tooltips to each model element that is normally displayed as 
an icon, keyed to the tooltip attribute.

> 2) LoadLeveler can provide additional, detailed information on a 
> submitted
> job, such as resources allocated to a job, reason why a job is not
> running, etc that we think would be useful to the user. Our 
> thinking here
> is that the user could right click on an entry in the job view and 
> get a
> popup menu witt 'detailed status' as one choice. Selecting that 
> results in
> a command to the proxy requesting status. The proxy sends back an 
> event
> with the detailed status. The GUI proceses that event and opens a 
> popup,
> scrollable, window displaying that status (or maybe put this info 
> in a new
> PTP view)

Or you could just send these as attributes on the job. Attributes are 
already displayed in the Properties view (Window->Show View- 
 >Properties) when you select a machine. I could change this so it 
worked with any model element you selected. This wouldn't require 
adding any new commands. Would this work for you?

> 3) It looks like the job view uses task indices starting at 0. 
> LoadLeveler
> identifies the application tasks in a parallel application using their
> task rank 0..n-1 and uses -1 for the master (poe) process of the
> application as well as -1 for the sole task of a serial 
> application. Is it
> possible to modify the definition of task index to allow -1 (and 
> maybe an
> arbitary lower linit)

I'll take a look, but I don't think there will be a problem. The 
'processIndex' attribute is used to calculate the ruler, so I think 
this would need to be updated to work with negative indices.

>
> Questions
> 1) Is the PID attribute to a process mandatory? This information is 
> not
> provided to us by LoadLeveler, so we would like to omit it, or use 
> '-1' as
> the pid if none is provided. We could also live with a requirement 
> that we
> send pid 0, but that woulod be a bit inconsistent with task index 
> where we
> have -1 as a task index.

I don't think so, but it shouldn't be in any case. It's only 
displayed in the tooltip and on the process details page (when you 
double click on a process icon). If you don't supply one then I think 
these are just blank.

>
> I also have a couple bugs which I will log in bugzilla when I get a 
> chance

Great!

Greg

_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev