|
|
 | | From: | Jogi Kuenstner | | Subject: | "formal" way to determine process-priority? | | Date: | Sat, 11 Dec 2004 03:28:56 +0100 |
|
|
 | Hi,
I am in the embedded realtime-world since years, but in the last months I
came over with a (known, but up to now ignored) problem to me:
In history I knew (at least I thought I'd ...) enough about the technical
stuff behind the software to fulfill specific requirements in our software,
so that we could have a rough guess about the needed priority for the
involved processes in our RTOS.
But our software is getting bigger, there are more people writing SW on the
system, so that it is more or less impossible to know all the necessary
details for finding out the right process-priority in our system.
So here comes my question:
Is there a more "formal" approach available for "guessing" or even better :
calculating process priorities.
I couldn't find any useful literature right now on the web, besides the
statements that one has to be careful about process-priorities. Helpful...
Also the "configurators" of the RTOSes I looked at, were no help, they only
represented a graphical view on some header-files for RTOS-configuration.
The system I am talking about is a mixture of a "standard"-RTOS mixed with
some proprietory extensions, but my question is RTOS-independent:
Is there a "questionnaire" which I can ask the designer of a subsystem to
find very fast enough information about the necessary priority?
e.g.:
- Latency,
- Runtime, until actively suspending on some resource or until "completion"
- relative priority in conjunction with the collaborators
- ...
And then: calculate xxx and yyy via zzz
Any hints? tools? questionnaires? ideas? ...
Regards
Jogi
--
The particular mistake will not be repeated. There are plenty of
mistakes left that have not yet been used. A. Tanenbaum
JogiKue@kuenstner.de
|
|
| | From: | Joseph Gwinn | | Subject: | Re: "formal" way to determine process-priority? | | Date: | Sat, 11 Dec 2004 18:43:33 GMT |
|
|
| In article ,
Jogi Kuenstner wrote:
> So here comes my question:
> Is there a more "formal" approach available for "guessing" or even better :
> calculating process priorities.
> I couldn't find any useful literature right now on the web, besides the
> statements that one has to be careful about process-priorities. Helpful...
> Also the "configurators" of the RTOSes I looked at, were no help, they only
> represented a graphical view on some header-files for RTOS-configuration.
> The system I am talking about is a mixture of a "standard"-RTOS mixed with
> some proprietory extensions, but my question is RTOS-independent:
> Is there a "questionnaire" which I can ask the designer of a subsystem to
> find very fast enough information about the necessary priority?
> e.g.:
> - Latency,
> - Runtime, until actively suspending on some resource or until "completion"
> - relative priority in conjunction with the collaborators
It's a part of the application system design, and cannot be relegated to
a tool, even if a tool is used. The key is to realize that importance
and priority are unrelated terms, and very important activities may or
may not be urgent. Importance is a human concept, incomprehensible to
computers. Priority is a number, which computers understand very well.
A classic example is that I/O interfaces must be handled immediately, to
keep the hardware happy, even if the data being read or written isn't
important, or isn't urgent. So, hardware interfaces generally have very
high priority.
Rate Monotonic (RM) methods have their place, but are no panacea,
especially in event-driven systems. Be aware that RM wants to assign
task priorities according to the fraction of the timeline each task
occupies, shorter durations leading to higher priorities, but that you
may need to assign priorities by some other rule, to achieve other
system requirements.
A good example is a radar I worked on in the late 1980s. The key was to
capture the data when available, and never lose anything. This data was
then extensively processed. The architecture was that the closer the
task was to the radar hardware, the higher the priority, with big queues
between the tasks. If some task took longer than average, which was
both common and unavoidable in that application, tasks closer to the
radar hardware data would elbow the slow task aside and run,
accumulating the results in the queues. Later, when the slow task
finally finished, it would find more stuff to work on. No data was lost.
Anyway, one could not implement rate-monotonic in this architecture
without giving up on a major requirement.
Joe Gwinn
|
|
| | From: | Pete Fenelon | | Subject: | Re: "formal" way to determine process-priority? | | Date: | Sat, 11 Dec 2004 03:40:06 +0000 |
|
|
| Jogi Kuenstner wrote:
> Is there a more "formal" approach available for "guessing" or even better :
> calculating process priorities.
Google is your friend. "Rate Monotonic Analysis" and "Deadline Monotonic
Analysis" may help you ;)
I'm aware of at least one RTOS that is integrated with a
schedulability-analysis tool that can suggest appropriate priority
allocations based on analysis of your application. Drop me an email...
pete
--
pete@fenelon.com "there's no room for enigmas in built-up areas"
|
|
| | From: | Jogi Kuenstner | | Subject: | Re: "formal" way to determine process-priority? | | Date: | Tue, 14 Dec 2004 23:31:07 +0100 |
|
|
| Pete Fenelon wrote:
> Jogi Kuenstner wrote:
>> Is there a more "formal" approach available for "guessing" or even better
>> : calculating process priorities.
>
> Google is your friend. "Rate Monotonic Analysis" and "Deadline Monotonic
> Analysis" may help you ;)
>
> I'm aware of at least one RTOS that is integrated with a
> schedulability-analysis tool that can suggest appropriate priority
> allocations based on analysis of your application. Drop me an email...
>
> pete
Hi,
even if I request in parallel more info via email,
the hints where helpfull, right now I am the brandnew owner of
2 interesting books, at least one covering some aspects of "Rate Monotonic
Analysis".
Only for reference, the two books are :
- "Real-time Systems" , by Jane W. S. Liu
- "Real-Time Concepts for Embedded Systems" by Qing Li
Thanks for the hints
Jogi
--
The particular mistake will not be repeated. There are plenty of
mistakes left that have not yet been used. A. Tanenbaum
JogiKue@kuenstner.de
|
|
|
