Summary of Realtime discussions (3/6/96-3/8/96)

Arindam Saha (saha@erc.msstate.edu)
Wed, 13 Mar 1996 14:38:33 -0600

SUMMARY OF THE REAL-TIME SUBCOMMITTEE DISCUSSIONS (3/6/96-3/8/96)
(as presented to the MPI Forum on 3/8/96)

Attendees present:

Ron Brightwell (Sandia)
Joel Clark (Intel)
Robert George (MSU)
Shane Hebert (MSU)
Arkady Kanevsky (MITRE)
Koichi Konishi (NEC)
Llyod Lewins (Hughes)
Arindam Saha (MSU)
Lance Shuler (Sandia)
Steven Taylor (CalTech)

- Insufficient participation in Vienna, no minutes

- MPI/RT will not determine but provide tools to implement the following
paradigms:
* priority based
* time driven
* event driven
* ad hoc

- MPI/RT will not replace the native runtime system or scheduler, but will
provide a portable API to these systems

- Embedded MPI will not have the full functionality of MPI/RT
* core will provide basic sends/receives, collective, and datatypes
* remaining functionality to be added on layers

- Abstraction of Layers
APPLICATION
________________________________
|
|
SYSTEMS PROCESSES |
|
________________________________|________ __________ _______
/ / / /
/ / / /
MPI/RT / / / /
/ / / /
____________________________________/ /_________/ /___________

KERNEL

________________________________________________________________

- "info" is a mechanism for application to communicate with the kernel
* signals in addition to KILL are required like SLEEP, RESUME, etc.
* we may communicate start time, priority, deadline to the kernel

- "notify" may be a mechanism to transmit information from kernel to the
application

- TIMEOUTS will be provided both on the sender and the receiver sides
* can be added unobtrusively with MPI_WAIT

- MPI/RT will provide access to a globally synchronized clock
* essential for time driven
* use one if available
* software synchronize if not available

- predicatabilty and QoS guarantees are important
* virtual channels may be one way to do it

- message scheduling will be by passing the opaque INFO argument at the time
of creation of the communicator

- develop a reprsentative suite of real world applications for
proof-of-concept

- preemption needed (especially to minimize priority inversion)

- fault tolerance is a desirable feature
* PERHAPS IT'S TIME TO HAVE A SERIOUS PROPOSAL ON FAULT TOLERANCE

If you have any comments please contact me.

Thanks.

-Arindam Saha
Mississippi State University
saha@erc.msstate.edu
601 325 2168