*** SEPTEMBER 1995 REAL-TIME MPI COMMITTEE NOTES **
Present: A. Kanevsky (MITRE), L. Lewins (Hughes), R. Babb (U. of Denver),
R. Brightwell (MSU), N. Doss (MSU), D. Cottel (NRaD).
The group reaffirmed the goals of real-time MPI to provide communications
with predictability & guaranteed timing performance. The real-time MPI
will allow middleware (implemented in the application for now)
to schedule communication resources and their interaction with computation
and other resources.
It was agreed that most of these goals can be better met if the operating
system supports real time. The performance will suffer without
real-time OS support but it is still feasible. We just need to establish
upper and lower bounds on the times required for data transfer and other
operations.
Lloyd Lewins presented results of the timing behavior of point-to-point
data transfer operations of MPI on the Mercury Raceway with and
without contention for various message sizes.
Three real-time methodologies were revisited:
time driven
event driven
priority based.
There was a discussion on how a single interface will support all
the methodologies.
It was decided to choose one methodology first and develop the RT MPI
for it. With the experience gained, the other methodologies will be examined.
Arkady presented the outline of a proposed RT MPI for the time driven
methodology (see enclosed). Most of the meeting went into the discussion of
this proposal.
It was pointed out that without having an operating system that
supports time driven scheduling it is expected that RT MPI will not
provide predictable high performance. There was a short discussion on the
MARUTI operating system developed at U. of Maryland that supports time
driven mechanisms for a distributed environment.
Arkady's time driven proposal consisted of four topics:
1) global synchronized clock,
2) starting time for individual operations,
3) timeout for individual operations, and
4) instrumentation.
Only the first three topics were discussed.
It was agreed that existing clocks in MPI (WTIME) are not sufficient.
However, instead of adding various operations to return synchronized
clock parameters, it may be better to add an "out" parameter
that returns these attributes of the synchronized clock to the
existing MPI_WTIME_IS_GLOBAL operation. The only attribute the group
agreed to add for now is maximum skew.
There were long discussions on starting times and timeouts
but no agreement was reached. However it was pointed out that
timeouts may be of interest not only to the real-time group but
a broader audience, especially client-server application developers.
Lloyd presented the group findings to the full MPI meeting on the last day.