July, 1996

• STATUS OF DOCUMENTATION:
  An online demo and online flyer were added to the Web pages. At the same time, the Adopter's Guide was prepared in its initial draft. A draft of the User's Guide has also been mounted on the Web.
  MQM was included (item 2.3.11) in the Guidelines for Writing System Software and Tools Requirements adopted by the National Coordinating Office for HPCC in July, 1996.
  A technical report describing MQM is now available through Oregon State University.

• STATUS OF GRAPHICAL TOOL:
  The graphical interface is unchanged since the previous status report.

• INTERFACE BETWEEN IPD AND MQM:
  Also unchanged. At the Ptools Annual Meeting, Intel representatives discussed plans to integrate MQM in future releases of both IPD and XIPD.

• INTERFACE BETWEEN AIMS AND MQM:
  Work has begun on the AIMS implementation, as a joint effort involving NASA/Ames and Los Alamos National Laboratory.

• STANDARD QUERIES:
  Unchanged.

December, 1995

• STATUS OF GRAPHICAL TOOL:
  A Tk/Tcl graphical interface has been developed in prototype form to show:
  • the system overview presenting information of message queues on all processes at a gross scale
  • an overview of message queues on a subset of processes
  • a detailed process-level view showing all pending operations for the process
  • a filter window allowing specifying certain messages to be viewed selectively
• INTERFACE BETWEEN IPD AND MQM:
  Integration between Intel's IPD and MQM has been successfully completed.
• STANDARD QUERIES:
  Right now, MQM actively queries the message passing system for message queue information whenever the data is needed. We feel the need to allow passive querying, which means that MQM queries for message queue data only when the underlying message passing system or the parallel tool into which MQM is incorporated allows. This way, the message passing system or the parallel tool incorporates MQM can be in charge instead of MQM.

June 30, 1994

• Intel
• NASA/Ames
• Oregon State University

Additional input from:

• PVM group (Al Geist, Jim Kohl, Jack Dongarra)
• MPI group (Rusty Lusk)
• assorted user representatives contacted by Oregon State

The MQM working group was approved in early spring. Work has proceeded concurrently along several veins, as described below.

• Structure of MQM:
  The basic organization of MQM and its interface to the underlying message system was sketched only vaguely in the proposal. With input from Intel and NASA/Ames, Oregon State developed a structure that would isolate the query functions into a separate object layer. This will allow the modification of queries to suit the messaging system, without modification of the tool itself. A diagram of the structure will be found in the WWW pages of the working group.
• Interface between MQM and XIPD:
  Discussions were held between Intel and Oregon State to determine what additional capability would need to be added to XIPD in order to interface cleanly to MQM. The isolation of the queries into a customizable layer will ameliorate most of the problems.
• Interface between MQM and AIMS:
  NASA/Ames did preliminary trials to establish the feasibility of acquiring the needed information on message queues through the AIMS monitor (AIMS supports either NX or PVM message passing). All problems appear to be resolvable.
• Interface between MQM and PVM:
  Oregon State and the PVM group discussed the feasibility of modifying the PVM daemon code to handle MQM queries. This would be a simpler solution for PVM programmers, since they would not need to install and use AIMS in order to obtain the information. Although PVM may not support the message deletion feature, they have tentatively agreed to support the other queries directly.
• Interface between MQM and MPI:
  Oregon State and the MPI group discussed the feasibility of doing something similar with MPI. MPI provides some features to support tool development; however, their structure would require that all message operations be traced fully in order to determine the instantaneous state of the queues. Discussions at the General Meeting confirmed that this is too high an overhead to incur for the simple functionality of MQM. MPI will consider future support for capturing dynamic snapshots of the system, the type of support needed by MQM.
• Scalability of Visual Representations:
  A team at Oregon State addressed the issue of how visual representations for the user interface would scale for hundreds of processes and potentially thousands of messages. There is no current tool which deals with this problem for messages, although a number of other efforts (chiefly in the area of performance analysis tools) were examined for potential application to MQM. The result of the study was the decision to provide hierarchical display formats: a system overview presenting information on all processes at a gross scale, and a "zoomed" view presenting detailed information on a selected process. Both views will support the filtering operations described in the proposal. Drafts of the views were presented in the working group's breakout session at the General Meeting and were assessed as acceptable.

This document was last updated 13 July '95.

July 12, 1995

STATUS OF GRAPHICAL TOOL:

• the system overview presenting information of message queues on all processes at a gross scale
• an overview of message queues on a subset of processes
• a detailed process-level view showing all pending operations for the process
• a filter window allowing filtering out specific messages

INTERFACE BETWEEN IPD AND MQM:

Nov. 8, 1994

STATUS OF GRAPHICAL TOOL:

• the system overview presenting information of message queues on all processes at a gross scale
• an overview of message queues on a subset of processes

The primary design questions centered around how to manage the numerous filtering options in a straightforward, self-explanatory way. After testing a variety of mechanisms, we decided to divide filtering options into two types:

• show/hide specific types of operations
• show/hide messages with specific sources/destinations/types

A query manager that is in charge of querying the message passing system and managing the message data has also been implemented. MQM can be hooked up with any message passing systems once their standard format query is implemented.

Next, we will develop a prototype form of lower-level displays. That includes view of pending message operations associated with an individual process, and detailed view of message contents.

The prototype will be demonstrated at the Parallel Tools Consortium booth at SC'94.

STANDARD QUERY FORMAT:

Sept. 14, 1994

STATUS OF GRAPHICAL TOOL:

The primary design questions centered around how to manage the numerous filtering options in a straightforward, self-explanatory way. A variety of mechanisms were tested, after user input was employed to develop a user-oriented scheme for grouping messaging operations into logical subsets.

There was also considerable design work in establishing mechanisms that would provide intuitive support for process subset filters. A test version of this was shown to users at NCAR in August, who concurred that the clearest way was to include an explicit how-to message directly in the subset window.

One problem with the user interviews is that, since no existing tool offers "snapshot" views of message queues, users aren't certain how such a facility would be used in typical programming scenarios.

We hope to have a full prototype ready for user feedback by the end of September.

STANDARD QUERY FORMAT:

NTERFACE BETWEEN MQM AND AIMS:

The draft implementation works as follows: Each application sets up an interrupt handler before commencing execution. On request by the user (e.g., via ^C), the application is halted by a signal, triggering activation of a handler which accomplishes the MQM functional operations:

• delete message that should not have been sent: handler removes it from someone's message queue
• simulate message (that wasn't really sent): handler composes a message and sends it
• ignore a receive that should not have been posted: handler constructs a message that will satisfy the posted receive
• terminate reduction operation: handler simulates the reduction operation in nodes that failed to participate.
• force completion of a barrier synchronization for which a node did not check in: handler simulates participation in the barrier.

INTERFACE BETWEEN MQM AND IPD: