On Mon, 16 Sep 1996, Arkady Kanevsky wrote:
> Date: Mon, 16 Sep 1996 13:41:37 -0400
> From: Arkady Kanevsky <arkady@linus.mitre.org>
> To: mpi-realtime@mcs.anl.gov
> Subject: initialization and QoS proposals
>
> ----------
> X-Sun-Data-Type: text
> X-Sun-Data-Description: text
> X-Sun-Data-Name: text
> X-Sun-Content-Lines: 8
>
> 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}
>
>
Anthony Skjellum, PhD, Associate Professor of Computer Science;
Mississippi State University, Department of Computer Science & NSF ERC
Butler, Rm 300, PO Box 9637, Corner of Perry&Barr, Mississippi State,MS 39762
(601)325-8435 FAX: (601)325-8997; http://www.erc.msstate.edu/~tony; Quote:
"What a rain of ashes falls on him that sees the new and cannot leave the
old."-Shakespeare ; e-mail: tony@cs.msstate.edu; Try MPI!