Scheduling Polices and soft realtime doubts in RTAI/Fusion

[Jan Kiszka]

Rodrigo Rosenfeld Rosas wrote:
> Hi all, specially Gerum and Paolo that have already helped me a lot!
> 
> My advisor asked me to talk to his students about real-time Linux. I'm
> likely to talk mostly about RTAI/Fusion. The course is about RTOS. I
> have some doubts and would like you to help me. The class will be on
> Tuesday.
> 
> I've looked for the scheduling policy used by RTAI and Fusion but did
> not find. Is there any documentation that states this? I would like to
> know what is the default policy used and if it is possible to choose
> another one and how to do it. I've found a message from Guru that states:
> [...
> RTAI supports FIFO and Round Robin.

The foundation is priority-base scheduling, identical priorities are
either handled according to FIFO or Round Robin policy.

> It also supports RMS and EDF with YOUR HELP.
> 

RMS can easily be mapped on prio-based scheduling schemes. EDF requires
a bit more work when doing this without some native support of the
scheduler as it is the case with fusion.

> read the file for more details:
> Documentation/README.SCHED_POLICY
> ...]
> 
> I didn't find this file in recent releases both from RTAI 3.2 and Fusion
> 0.8.2.
> 
> I found that Fusion is able to support the O(1) scheduler, as available
> in the 2.6 series. What is the default policy? Is O(1) the only
> alternative for the scheduler?

O(1) is about queuing and dequeuing task objects according to their
current priority. The feature of the scheduler (RTAI_OPT_SCALABLE_SCHED)
is currently switched off by default. Note: this is not a scheduling
policy, it's an implementation detail.

> 
> The other question is about the soft realtime concept. It is not clear
> to me the differences between a soft realtime task and a no realtime
> task at all. The soft realtime task is scheduled by the Linux scheduler
> doesn't it? So, what is the difference between a soft realtime task and
> a normal Linux process or thread? I understand that the difference is
> that if the task is periodic it will execute in the specified period.
> But I think I could archieve a similar result with a regular Linux task
> and some programming. So, I guess that the soft realtime has a priority
> greater then Linux so that Linux only runs when no soft or real realtime
> task is running. But that would yield to another doubt. How could that
> happen if the task is scheduled by Linux. What would be the difference
> between hard and soft real-time? I know that a hard realtime can't
> execute linux calls in hard-realtime and that the hard realtime have
> priorities greater than soft realtime ones. What about the other
> differences? And what happen if a deadline is missed both for a soft and
> a hard realtime task? I know the programmer can verify if a deadline was
> missed, but if he/she doesn't test it what is the behaviour?
> 

The term "soft real-time" comes with RTAI 3.x (LXRT), in fusion it is
called "secondary mode". For LXRT it means that the task can use
real-time services and it's priority is raised during this period - it
becomes "hard real-time". While being soft, no guarantees on the tasks
timing behaviour can be provided (due to standard Linux).

Fusion does it the other way around: a hard real-time user space task (a
task in "primary mode") can call non-real-time Linux services. During
this period it will be switched to secondary mode - kind of LXRT's soft
real-time mode, but with all interrupt sources for Linux (not for RTAI!)
switched off. This is intended to improve the execution latency of the
task in secondary mode, but it still requires some synchronisation with
Linux, thus it is not that deterministic as the primary mode (it's still
wise not to count on some worst-case execution time of that phase).

> Sorry for this lot of questions, but I sware I've been looking for this
> information about 2 days (my advisor asked me on Friday) and found
> nothing solid. Maybe I'm looking in the wrong places. Hopefully you can
> enlight me.
> 

Hope I could helped a bit. Good luck for Tuesday,

Jan