Assigning task priorities for a RTOS system

Dear Experts,
I am curious to understand how we go about setting priorities for an
RTOS  system.I have heard in one of our training sessions that when we
set priorities,generally processing task would get highest priority
and then the input task and then the output task.How can we decide
which priority to assign for a particular task?
I am aware this query is too generic to be answered and its more
application specific.It will help me to understand if you could give
me the samples from the applications you have dealt with?
This will help me to design a whole system from scratch.Till date I
have not got a chance to design a new system.But in future I believe I
would be involved in such a task.Mainly the following applications
would be of more interest to me :
1)Industrial automation systems using RTOS where you sense inputs
through sensors and later you do some processing and then send your
output to actuators.
2)Consumer electronics application involving audio/video systems
3)Aeronautical applications
4)UI related applications like bank Automated Teller machines
5)Telecom systems involving switching

Looking farward for all your replies and advanced thanks for the same,

P.S:I have cross posted it in comp.realtime group also to attract more
replies.

Regards,
s.subbarayan

In article <5a60837a-7f3b-44d2-b7c4-96471d9266a9
@d27g2000prf.googlegroups.com>, ssubbarayan says...
> Dear Experts,
> I am curious to understand how we go about setting priorities for an
> RTOS  system.I have heard in one of our training sessions that when we
> set priorities,generally processing task would get highest priority
> and then the input task and then the output task.How can we decide
> which priority to assign for a particular task?

Well, here's an overview

http://en.wikipedia.org/wiki/Scheduling_%28computing%29

Rate monotonic is fairly common in small systems.

Robert

-- 
Posted via a free Usenet account from http://www.teranews.com

"ssubbarayan" <ssubba@gmail.com> wrote in message
news:5a60837a-7f3b-44d2-b7c4-96471d9266a9@d27g2000prf.googlegroups.com...
> Dear Experts,
> I am curious to understand how we go about setting priorities for an
> RTOS  system.

The assignment of the task priorities in RTOS is a vast area and there are
tons of literature about it. In short, if the CPU load is below 70%, the
simple strategies like the task with the closest deadline gets the highest
priority or the task which requires the fastest response gets the highest
priority are working very well. If the workload is higher then 70%, then the
priority assignment gets very complicated and the application specific, too.

Vladimir Vassilevsky
DSP and Mixed Signal Consultant
www.abvolt.com

On Dec 7, 11:17 pm, "Vladimir Vassilevsky"
<antispam_bo...@hotmail.com> wrote:
> "ssubbarayan" <ssu...@gmail.com> wrote in message
> > Dear Experts,
> > I am curious to understand how we go about setting priorities for an
> > RTOS  system.
>
> The assignment of the task priorities in RTOS is a vast area and there are
> tons of literature about it. In short, if the CPU load is below 70%, the
> simple strategies like the task with the closest deadline gets the highest
> priority or the task which requires the fastest response gets the highest
> priority are working very well. If the workload is higher then 70%, then the
> priority assignment gets very complicated and the application specific, too.

Or you use EDF (earliest-deadline first) scheduling and you can go up
to 100% utilization.
If you insist on static priority scheduling RMA (rate monotonic
analysis)  will tell you whether your
task system is schedulable.

- Bjoern

Bj=F6rn wrote:
> On Dec 7, 11:17 pm, "Vladimir Vassilevsky"
> <antispam_bo...@hotmail.com> wrote:
>=20

>>The assignment of the task priorities in RTOS is a vast area and there =
are
>>tons of literature about it. In short, if the CPU load is below 70%, th=
e
>>simple strategies like the task with the closest deadline gets the high=
est
>>priority or the task which requires the fastest response gets the highe=
st
>>priority are working very well. If the workload is higher then 70%, the=
n the
>>priority assignment gets very complicated and the application specific,=
 too.
>=20
>=20
> Or you use EDF (earliest-deadline first) scheduling and you can go up
> to 100% utilization.

Unfortunately, no. EDF works fine for the moderate load conditions,=20
however if the CPU load is already high it increases the overhead=20
further. Many tasks are competing, there is a lot of unnecessary=20
rescheduling.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

In article 
<46c88e29-ad18-4a75-9bfe-a744df9b7ced@b1g2000pra.googlegroups.com>,
 "Bj&#4294967295;rn" <askadar@gmail.com> wrote:

> On Dec 7, 11:17 pm, "Vladimir Vassilevsky"
> <antispam_bo...@hotmail.com> wrote:
> > "ssubbarayan" <ssu...@gmail.com> wrote in message
> > > Dear Experts,
> > > I am curious to understand how we go about setting priorities for an
> > > RTOS  system.
> >
> > The assignment of the task priorities in RTOS is a vast area and there are
> > tons of literature about it. In short, if the CPU load is below 70%, the
> > simple strategies like the task with the closest deadline gets the highest
> > priority or the task which requires the fastest response gets the highest
> > priority are working very well. If the workload is higher then 70%, then the
> > priority assignment gets very complicated and the application specific, too.
> 
> Or you use EDF (earliest-deadline first) scheduling and you can go up
> to 100% utilization.
> If you insist on static priority scheduling RMA (rate monotonic
> analysis)  will tell you whether your
> task system is schedulable.

Be aware that the achilles heel of all advanced scheduling algorithms is 
bad behaviour under overload, when there is more work than time to do 
it.  Given that RTOSs must handle external events, which cannot be 
predicted or controlled in any detail, overlaods are inevitable and must 
be handled gracefully, or the system will prove fragile in use.  This is 
why RTOSs traditionally use only simple hard-priority schedulers, or 
even round-robin.

That said, there is no reason that application-level scheduling cannot 
use an advanced algorithm, so long as overload of that algorithm cannot 
cause anything essential to stop.

Joe Gwinn

As compared to what?  RM?  EDF has a lower overhead than RM in the general 
case.


---Matthew Hicks


> Bj�rn wrote:
> 
>> On Dec 7, 11:17 pm, "Vladimir Vassilevsky"
>> <antispam_bo...@hotmail.com> wrote:
>>> The assignment of the task priorities in RTOS is a vast area and
>>> there are tons of literature about it. In short, if the CPU load is
>>> below 70%, the simple strategies like the task with the closest
>>> deadline gets the highest priority or the task which requires the
>>> fastest response gets the highest priority are working very well. If
>>> the workload is higher then 70%, then the priority assignment gets
>>> very complicated and the application specific, too.
>>> 
>> Or you use EDF (earliest-deadline first) scheduling and you can go up
>> to 100% utilization.
>> 
> Unfortunately, no. EDF works fine for the moderate load conditions,
> however if the CPU load is already high it increases the overhead
> further. Many tasks are competing, there is a lot of unnecessary
> rescheduling.
> 
> Vladimir Vassilevsky
> DSP and Mixed Signal Design Consultant
> http://www.abvolt.com

External events are handled by an aperiodic server.  Overloads in general 
can be handled many ways, it all depends on how you want your system to work. 
 But all of this is orthogonal to the scheduling policy you choose.  All 
of these problems have been solved and all but the optimial solutions are 
effecient.


---Matthew Hicks


> In article
> <46c88e29-ad18-4a75-9bfe-a744df9b7ced@b1g2000pra.googlegroups.com>,
> "Bj&#4294967295;rn" <askadar@gmail.com> wrote:
>> On Dec 7, 11:17 pm, "Vladimir Vassilevsky"
>> <antispam_bo...@hotmail.com> wrote:
>>> "ssubbarayan" <ssu...@gmail.com> wrote in message
>>> 
>>>> Dear Experts,
>>>> I am curious to understand how we go about setting priorities for
>>>> an
>>>> RTOS  system.
>>> The assignment of the task priorities in RTOS is a vast area and
>>> there are tons of literature about it. In short, if the CPU load is
>>> below 70%, the simple strategies like the task with the closest
>>> deadline gets the highest priority or the task which requires the
>>> fastest response gets the highest priority are working very well. If
>>> the workload is higher then 70%, then the priority assignment gets
>>> very complicated and the application specific, too.
>>> 
>> Or you use EDF (earliest-deadline first) scheduling and you can go up
>> to 100% utilization.
>> If you insist on static priority scheduling RMA (rate monotonic
>> analysis)  will tell you whether your
>> task system is schedulable.
> Be aware that the achilles heel of all advanced scheduling algorithms
> is bad behaviour under overload, when there is more work than time to
> do it.  Given that RTOSs must handle external events, which cannot be
> predicted or controlled in any detail, overlaods are inevitable and
> must be handled gracefully, or the system will prove fragile in use.
> This is why RTOSs traditionally use only simple hard-priority
> schedulers, or even round-robin.
> 
> That said, there is no reason that application-level scheduling cannot
> use an advanced algorithm, so long as overload of that algorithm
> cannot cause anything essential to stop.
> 
> Joe Gwinn
> 

On Sat, 08 Dec 2007 04:17:59 GMT, "Vladimir Vassilevsky"
<antispam_bogus@hotmail.com> wrote:

>
>"ssubbarayan" <ssubba@gmail.com> wrote in message
>news:5a60837a-7f3b-44d2-b7c4-96471d9266a9@d27g2000prf.googlegroups.com...
>> Dear Experts,
>> I am curious to understand how we go about setting priorities for an
>> RTOS  system.
>
>The assignment of the task priorities in RTOS is a vast area and there are
>tons of literature about it. In short, if the CPU load is below 70%, the
>simple strategies like the task with the closest deadline gets the highest
>priority or the task which requires the fastest response gets the highest
>priority are working very well. If the workload is higher then 70%, then the
>priority assignment gets very complicated and the application specific, too.

I would put that limit much lower, perhaps somewhere around 40 % with
specific timing requirements. 

Anyway, you can use 100 % CPU loading, as long as the remaining tasks
are not time critical. For instance you could run optimization in the
Null task until the result is actually required and be satisfied with
a possibly suboptimal result.

Paul

Paul Keinanen wrote:
> On Sat, 08 Dec 2007 04:17:59 GMT, "Vladimir Vassilevsky"
> <antispam_bogus@hotmail.com> wrote:
> 
>> "ssubbarayan" <ssubba@gmail.com> wrote in message
>> news:5a60837a-7f3b-44d2-b7c4-96471d9266a9@d27g2000prf.googlegroups.com...
>>> Dear Experts,
>>> I am curious to understand how we go about setting priorities for an
>>> RTOS  system.
>> The assignment of the task priorities in RTOS is a vast area and there are
>> tons of literature about it. In short, if the CPU load is below 70%, the
>> simple strategies like the task with the closest deadline gets the highest
>> priority or the task which requires the fastest response gets the highest
>> priority are working very well. If the workload is higher then 70%, then the
>> priority assignment gets very complicated and the application specific, too.
> 
> I would put that limit much lower, perhaps somewhere around 40 % with
> specific timing requirements. 
> 

Please elaborate.  Why 40%?  According to my understanding of RMA
scheduling, a CPU utilization figure of very nearly 70% will guarantee
deadlines are met when the number of tasks is large.  If the number of
tasks is small, then it will be possible to meet the deadlines with
greater CPU utilization.

True, those values don't take into account the overhead of context
switches and scheduling and so forth.  It seems unlikely that in
practice one would be faced with that much overhead.


Brian