Enclosed, please,
find the Real-Time Initialization and QoS sections
that reflect our discussions at the Chicago September meeting.
The sections are in LaTeX format to simplify Tony's job of merging
these sections with the overall chapter.
Arkady
----------
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: init.tex
X-Sun-Content-Lines: 50
\section{Starting and Finishing of Real-Time {\MPI/}}
In order to start the \MPI/ an application process needs to do
{\tt MPI\_INIT} before any other operation of the \MPI/. After the
{\tt MPI\_FINALIZE}, no other \MPI/ operation is allowed.
For the real-time \MPI/ we are going to provide analogous operations
that are needed to start and finish the use of {\MPI/}\RT operations.
Since there maybe more than one profile of the real-time \MPI/
(do not confuse with different paradigms which this chapter provides)
and to be backward compatible with the existing \MPI/, the initialization
operation of the {\MPI/}/RT will have a single input parameter that specifies
a requested profile.
\begin{funcdef}{MPIRT\_INIT(profile)}
\funcarg{\IN]{profile}{ the {\MPI/}\RT profile to be initialized}
\end{funcdef}
After {\tt MPIRT\_INIT} returns successfully, the attributes of a synchronized
clock described in the next section become initialized and accessible.
\discuss{
What profiles should we have?
So far we discussed only three profiles: \MPI/, full \MPI/ and {\MPI/}/RT, and
{\MPI/}/RT only.
Several other profiles were also mentioned: profile for each paradigm,
embedded \MPI/ profile.
We should not have too many profiles otherwise the portability and
interoperability will suffer.
If we include more than discussed profiles we should also consider
the ability of the application to switch from on profile to another.
Recall, that currently, once the {\tt MPI\_FINALIZE} is called you can not
call {\tt MPI\_INIT} again.}
For completeness we also include
\begin{funcdef}{MPIRT\_INITIALIZED(profile)}
\funcarg{\OUT}{profile}{the initialized MPIRT profile}
\end{funcdef}
that returns FALSE if {\MPI/}/MPIRT not initialized and returns TRUE
and the profile in the OUT profile parameter if it is.
Finally,
\begin{funcdef}{MPIRT\_FINALIZE}
\end{funcdef}
closes the {\MPI/}/RT interface.
\end{document}
----------
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: outline.tex
X-Sun-Content-Lines: 71
\section{QoS}
The quality of service parameters span point-to-point
persistent channel, collective persistent channels and
all paradigms of real-time discussed in this chapter.
The QoS parameters are the most important distinction between
regular \MPI/ and real-time \MPI/.
The quality of service parameters currently under consideration
are divided into two categories:
paradigm specific and underlying lower level QoS parameters.
While details of specification are not fully fleshed out,
here are some of the QoS parameters for individual paradigms.
\begin{description}
\item[Time-Driven]
The QoS parameters for time-driven paradigm include:
\begin{itemize}
\item
time interval for message transmission,
\item
period, for periodic message transmission,
including the relationship between the ime interval and the period,
usually defined by a release time and a deadline,
\item
maximum message size.
\end{itemize}
\item[Event-Driven]
The event-driven paradigm does not have any QoS parameters
per se. However, when we will consider the merged paradigm, the QoS
parameters for priority and time-driven paradigms will be added
here as needed.
\item[Priority-Driven]
The QoS parameters for priority driven paradigm include:
\begin{itemize}
\item
Integer priority of the persistent channel for message transmission,
\item
maximum message size.
\end{itemize}
Currently, there are no deadline associated with the message transmission
for the priority-driven paradigm.
\end{description}
The lower level underlying QoS parameters are the network level
QoS parameters.
So far we have discussed: bandwidth and latency.
The details of specification for both of them are still under
discussion. While for some examples in this chapter we stated the percentage
of the bandwidth associated with the channel, in reality an application
is not necessarily aware of the total point-to-point bandwidth. So it is
more appropriate for the application to request the channel bandwidth specified
by bytes per second.
It is still unclear if an application really needs to specify lower
level QoS parameters. It can be a job of
a platform specific MPI implementation to
translate higher level application QoS parameters to the platform/network
specific lower level parameters.
In this case, the application QoS
will be satisfied by the {\MPI/}\RT, while the network will satisfy {\MPI/}\RT
QoS parameters which {\MPI/}\RT implementation requests from the underlying
network/platform based upon the application request.
The next section presents the most
commonly used network real-time QoS parameters.
\end{document}