This is a very good wish list.
I suggest that the first three bullets of the first recommendation
should be considered as a starting point for "soft" QoS.
The last bullet of the first recommendation should be discussed further
as a part of mixed paradigm models.
Finally the last recommendation (all three bullets) can be addressed
as advice to implementors. MPI/RT does not want to dictate to implementors
how to do schduling on their platform and instead provide advices that
can be utilized on some platforms if implementor(s) deem(s) that appropriate.
Kelvin, these are very good suggestions and advices. I would like
to thank you for them and encourage everybody to follow his example
to have a more active discussion via email and not only at the meetings.
Arkady
> From mpi-realtime-human@mcs.anl.gov Mon Dec 9 23:54:04 1996
> X-Sender: kelvin@newmonics.com
> X-Mailer: Windows Eudora Pro Version 3.0 (32)
> Date: Mon, 09 Dec 1996 22:41:01 -0600
> To: mpi-realtime@mcs.anl.gov
> From: Kelvin Nilsen <kelvin@newmonics.com>
> Subject: MPI/RT Wish List
> Cc: kelvin@newmonics.com
> Mime-Version: 1.0
> Content-Type> : > text/plain> ; > charset="us-ascii">
> Sender: owner-mpi-core@mcs.anl.gov
> Content-Length: 3384
>
>
> At the MPI/RT meeting last week, I expressed several preferences regarding
> "improvements" to the MPI/RT standard. In general, Arkady suggested that
> such requests should be brought to the attention of the larger group by way
> of this mail list.
>
> Here they are:
>
> 1. In order to provide good performance for a reasonable price, I believe
> it is important to allow applications to make use of network resources
> that cannot always be guaranteed. (Yes, I understand that certain
> critical activities need guaranteed quality of service, but there are
> many examples of real-time applications for which variable quality of
> service is perfectly reasonable.) Here are some of the ways in which
> I would like to specify the service quality of a channel:
>
> a) At minimum, transmit Xm messages of Ym bytes each in each period of
> N msec. On average, transmit Xa messages of Ya bytes each in each
> period of N msec.
>
> b) In each period of N msec, transmit Xm messages of Ym bytes each
> with probability .99 of having such messages delivered (on time).
> If the message can't be delivered on time, throw it away.
>
> c) In each period of N msec, allow me to transmit, on average, Xm
> non-time-constrained messages with probability .95 that all Xm
> messages will be delivered. (If the messages being corrupted in
> transit, additional network resources will be required to correct
> the problem. One out of every twenty periods on average, something
> less than the full Xm messages will be delivered.)
>
> d) This channel will be idle 99% of the time. However, once out of
> every 100 (on average) periods, this channel will have a message
> that must be transmitted with very high priority. (Note that
> idle channels can be combined with average/minimum service quality
> channels to support good average-case performance and guaranteed
> minimal functionality to handle "emergencies.")
>
> Note that I'm not asking for the system to allow messages to be delivered
> late.
>
> 2. Once a channel has been allocated, I'd like to be able to "manage" how
> the channel is used. For example:
>
> a) Individual messages might be prioritized as they are queued for
> transmission. The low-level network driver will transmit queued
> messages in prioritized order.
>
> b) At the receiver node, the receiving task may prioritize its
> processing of messages that are queued for reception. This
> prioritization can be implemented as a combination of sender
> priorities and guard conditions.
>
> c) A sender might queue a time-constrained message with a parameter
> that states the message's deadline for arrival at its destination.
> If the message cannot be delivered prior to the specified deadline,
> the system should not deliver the message at all. As an
> optimization, the sending node should discard the message without
> even attempting to transmit it as soon as it discovers that there
> is insufficient time remaining to meet the message's deadline.
>
>
>
> --
> Kelvin Nilsen, President voice: 515-296-0897
> NewMonics Inc. fax: 515-296-9910
> 2501 N. Loop Dr., Suite 614A http://www.newmonics.com
> Ames, IA 50010 email: kdn@newmonics.com
>