Here are the minutes of the December 5-6 MPI/RT meeting at MITRE.
Sorry for the delay.
Arkady, Tony and Anna.
----------
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: new_minutes_dec_96
X-Sun-Content-Lines: 120
Minutes of the MPI/RT meeting of December 5-6 at MITRE.
Attendees:
Dennis Cottel, NRAD
Jose Munoz, DARPA
Jerrell Watts, Caltech
Harish Nag, Intel
Rob Cunningham, MIT Lincoln Lab
Ron Brightwell, Sandia
Robbie Babb, U Denver
Anna Rounbehler, SKY Computer
Gerard Vichniac, Mercury
Tony Skjellum, MSU
Zhenqian Cui, MSU
Jim Li, MSU
Thomas H. Robey, Khoral Research
Don Fronterhouse, SSI
Clayton Keller, CSPI
Nathan Doss, Sanders
Steward Potter, Sanders
Alex Stoyenko, NJIT
Mike Hinchey, NJIT
Kelvin Nilsen, NewMonics
Arkady Kanevsky, MITRE
Richard Games, MITRE
Leonard Monk, MITRE
John Ramsdell, MITRE
Tom Wheeler, MITRE
The following issues were addressed:
1. The feedback from SC'96 was provided.
2. Jose Munoz provided the DARPA view on the role of MPI/RT.
3. The chapter was presented as a whole for the first time.
4. Channel topologies were discussed. Some diagrams and how users
can create virtual topologies they desire using existing channel
functionality will be added.
5. Buffer management was discussed.
It was suggested that a method for allowing to hook application
specific modules to do queue management both for implementation
and user sides is needed. Changes from constants to symbols will
be added wherever appropriate.
Ron and Jerrell will update the section for the next meeting.
6. The Soft QoS, Ad-hoc and other profiles were discussed.
The following agreement was voted - There is no Ad-hoc profile.
This section will be removed.
The soft vs hard dichotomy seems to be misleading.
The consensus was building but not voted on along the following interpretation:
Hard represents the guarantee of service and appropriate user
specified error handlers that can
be invoked when the service is not delivered.
The Soft QoS represents the conditions when an error handler will be invoked.
The underlying assumption before was that for the hard QoS paradigms the error
handlers are invoked every time the QoS service is not delivered.
For the soft QoS the user can specify that only when the error rate fall
outside some user specified parameters then the error handlers are invoked.
The details how it is specified were discussed but no decision was reached.
According to this view Soft vs Hard QoS is not a dichotomy but two orthogonal
issues.
Notice that in this soft vs hard separation, the Priority
paradigm falls outside hard QoS realm. There are some suggestions to add
deadline or some other parameters to bring priority paradigm back into
hard QoS realm. The value of Ignorable can still be used to make
priority soft QoS. Tony, Arkady and Anna will take a stab at this proposal.
7. Fault tolerance was discussed with respect to QOS and error handlers
for channels. There is a desire to enlarge this capability to
capture errors of many different types that occur in
data transmission and over channels.
Four proposals were discussed:
A. Error handlers should be full capacity handlers with no restrictions
A smaller restricted subset may be considered in the future to
provide tighter guarantees.
B. Each channel will have a single error handler or separate handlers
for individual errors as defined by the user.
C. Warning should be added to compliment errors.
D. Some discussion centered on the issue of the error/warning queues
and the order in which they should be delivered. Even some attempts
to bring OS priorities at this level were discussed.
A combined proposal will be written by Jarrell, Arkady and Anna.
8. The instrumentation proposal was discussed in detail.
The following proposals emerged:
A. The need for hooks for monitoring/debugging.
B. Three separate monitors types are needed: request, communicator, other.
C. Change MPIRT_MONITOR_INIT to MPIRT_MONITOR_RESET.
D. The need for layered libraries support.
Anna, Jerrell, Dennis and Alex will write the details of the proposals.
9. The event driven paradigm was discussed in detail.
The relationship between communication scheduler and OS scheduler came into
discussion. It was pointed out that probably some caveat
with respect to the granularity of OS scheduler may be needed
for event driven QoS. Also the bound on the number of
events over a time interval may be needed in order for an MPI/RT implementation
to provide a QoS guarantee. This may be even more of a problem for
higher level event-driven model. Jerrell and Arkady will write a proposal
and present it to the group next time.
10. The mixture of the models is still a subject of intense discussion,
but the first order of business is to settle down individual paradigms.
There was however consensus building for only having two priority levels
for hard QoSs: one for emergency and one for regular service.
10. The time for the next MPI/RT meeting was not discussed.
There were a few suggestions about the next MPI/RT in February in Albuquerque,
NM or San Diego, CA. We will schedule it in January.